Acer M3WebServer EUVD-2026-34210

Exploitation requires only network reachability to the M3WebServer HTTP interface on an Acer Connect M6E 5G router running the production firmware build, plus the ability to trigger one of the verbose error-handling code paths that render the hard-coded backend API keys in the response. Per the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N), there are no authentication, user-interaction, or special configuration prerequisites, and the production build is the default shipping image rather than a debug mode the user must opt into. The principal limiting factor is exposure of the management interface: devices whose web UI is reachable only from the LAN constrain the attacker to on-link adversaries (including any WiFi client of the portable hotspot), while devices with WAN-side management exposed are reachable from the public internet.

The CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H describes a fully remote, low-complexity, zero-prerequisite attack against confidentiality, integrity, and availability of the vulnerable component - consistent with the 9.3 base score. EPSS, KEV listing, and SSVC decision data were not provided, so real-world exploitation probability cannot be quantified from the supplied intelligence, and there is no public exploit identified at time of analysis. The risk should still be treated as high-priority: hard-coded keys recovered from one device generalize to every device running the same firmware, which is the typical pattern that produces rapid post-disclosure exploitation against consumer routers. The single reference is the vendor's own community knowledge-base article, so claims about scope and fix availability could not be independently cross-referenced against NVD or third-party advisories.

An attacker on the same network segment (or across the internet, if WAN management is enabled) sends malformed or unexpected HTTP requests to the router's M3WebServer until a verbose error page is rendered, then extracts the embedded backend API keys from the response body. Using those keys, the attacker authenticates directly to the backend API to read configuration, alter routing or DNS, pivot into the connected LAN, or brick the device - no credentials, user interaction, or social engineering required.