CWE-311: Missing Encryption of Sensitive Data
CWE-347: Improper Verification of Cryptographic Signature
| | CVSS v4.0 Score | 8.2 (High) | | CVSS v4.0 Vector | `CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:N/SA:N` | | Discovered By | ThreadPoolX | *** ### Root Cause Analysis During hardware analysis, the 2MB SPI flash memory chip (e.g., EN25QH16) on the Mercusys AC12 V2 PCB was identified as the primary non-volatile storage medium. This chip contains the device bootloader, the operating system (VxWorks/Linux filesystem), and user configuration partitions (`ISPCONFIG`). Because the System-on-Chip (SoC) does not implement hardware-based transparent memory encryption, all data is stored on the SPI flash in pure plaintext. Furthermore, the bootloader does not enforce a cryptographic Secure Boot chain (such as verifying RSA/ECDSA signatures of the OS kernel prior to handoff). Because the boot process blindly trusts the contents of the SPI flash, an attacker can trivially manipulate the filesystem bits, and the device will boot the tampered operating system without triggering any integrity faults. *** ### Lab Environment & Tooling To replicate and verify this vulnerability, the following hardware and software tools are required: #### Hardware Requirements * **Target Device:** Mercusys AC12 V2 Router * **Hardware Programmer:** CH341A SPI Flash Programmer (or standard Raspberry Pi / Bus Pirate) * **Interconnects:** SOP8 Test Clip (eliminates the need for desoldering the flash chip) #### Software Requirements * **Operating System:** Kali Linux or Windows * **Reading/Writing Software:** NeoProgrammer, `flashrom` * **Analysis Tools:** `binwalk`, `vbindiff`, `hexedit` *** ### Proof of Concept (PoC) {% hint style="info" %} Using a SOP8 test clip allows for in-circuit programming (ICP). Ensure the router is completely powered off and unplugged from the wall adapter before attaching the clip to prevent voltage collisions. {% endhint %} 1. **Disassembly:** Open the outer casing of the router and locate the 8-pin SPI flash chip on the PCB (typically an EN25QH16 or equivalent 2MB IC). 2. **Hardware Hookup:** Attach the SOP8 test clip directly to the SPI flash chip. Connect the ribbon cable from the clip to the CH341A hardware programmer. 3. **Data Extraction:** Plug the CH341A programmer into the analysis workstation. Use a tool like NeoProgrammer or `flashrom` to dump the entire 2MB contents into a binary file: ```bash flashrom -p ch341a_spi -r original_dump.bin ``` 4. **Filesystem Analysis:** Run `binwalk` on the extracted `.bin` file to verify that the bootloader, OS, and configuration partitions are entirely unencrypted and easily carveable: ```bash binwalk -e original_dump.bin ``` 5. **Data Modification (Tampering):** Use `hexedit` or `vbindiff` to modify the extracted filesystem. (For example, enabling dormant services, injecting a backdoor binary, or altering root passwords). 6. **Flashing Malicious Payload:** Repack the modified firmware and flash it back onto the chip using the hardware programmer: ```bash flashrom -p ch341a_spi -w tampered_dump.bin ``` 7. **Execution:** Disconnect the SOP8 clip, power on the router normally, and observe that it boots the tampered firmware without any security warnings or bootlooping. *** ### Security Impact * **Persistent Code Execution (Hardware Backdoor):** Attackers can overwrite the bootloader or OS partitions to install persistent rootkits that survive factory resets and standard OTA firmware updates. * **Credential Exposure:** Total compromise of data confidentiality. Attackers can extract plaintext Wi-Fi passphrases, ISP PPPoE credentials, and administrator login hashes directly from the `ISPCONFIG` partition. * **Device Bricking:** The lack of write protections allows malicious actors to overwrite the bootloader entirely, rendering the hardware permanently inoperable (Denial of Service). *** ### Remediation Guidance #### Recommendations for Manufacturers 1. **Implement Secure Boot:** Utilize the SoC's hardware root of trust (if supported) to cryptographically verify the integrity of the bootloader and kernel during every boot sequence. 2. **Flash Encryption:** Implement AES-XTS or similar hardware-accelerated memory encryption for sensitive partitions (like `ISPCONFIG`) to prevent offline data extraction. 3. **Flash Write Protection:** Utilize the SPI flash chip's internal status registers to enforce write-protection (WP) on the bootloader sectors, preventing software-based overwrites. #### Recommendations for Network Administrators 1. Physically secure routing infrastructure in locked cabinets or restricted-access rooms to prevent unauthorized direct hardware interfacing. 2. When decommissioning networking hardware, physically destroy the SPI flash chip to ensure legacy network credentials cannot be recovered via hardware dumping. *** ### Timeline * **February 17, 2026:** Vulnerability identified via in-circuit SPI flash analysis. * **September 20, 2026:** CVE ID `CVE-2026-78860` officially assigned by MITRE. * **September 22, 2026:** Public disclosure writeup published by ThreadPoolX.