Mercusys AC12 EUVD-2026-92786

Exploitation requires local/physical access to a Mercusys AC12 V2 router: because the firmware is stored without encryption and the device lacks a secure boot mechanism, an attacker with hands-on access can read plaintext stored data and reflash or modify firmware to run arbitrary code. Limiting factors: there is no remote or network path (AV:L in the input, physically-realized in practice), so the attacker must obtain the physical device or its storage; this restricts realistic exploitation to supply-chain, resale, repair, theft, or evil-maid scenarios rather than mass remote attack.

Signals are consistent in pointing to a LOW real-world priority despite the 7.8 HIGH CVSS base score. The input CVSS vector (AV:L/AC:L/PR:L) already constrains this to a local attacker, and the underlying root cause - documented in the ThreadPoolX advisory as missing firmware encryption and secure boot - means the 'arbitrary code execution' requires hands-on access to the device's flash/firmware rather than any network-reachable path. EPSS is very low (0.16%, 5th percentile), there is no CISA KEV listing, and no public exploit code was identified, so this is not an actively exploited or opportunistically scannable issue. There is a notable tension between the input CVSS and the described vulnerability class: CVSS:3.1 encodes AV:L with PR:L, but a 'plaintext storage of information' / missing firmware encryption weakness is typically exploited via physical access to the device (AV:P) and generally needs no prior credentials (PR:N) - verify the exact access model with the vendor, as it materially lowers the realistic score. In short, this is a HIGH-CVSS, low-real-risk hardware/firmware hardening gap, relevant mainly to attackers with physical possession of the router (supply-chain, resale, or evil-maid scenarios), not remote threat actors.

An attacker with physical possession of a Mercusys AC12 V2 router (e.g., during resale, repair, or theft) connects to the flash/firmware interface and, because firmware is stored unencrypted and secure boot is absent, dumps the image to extract plaintext secrets or reflashes it with malicious code that executes on boot. No public exploit code was identified at time of analysis, and exploitation requires local/physical access rather than a remote network path.