TP-Link Archer C64 CVE-2026-8697

The attacker must have adjacent-network access to the Archer C64 v1 (typically associated to its Wi-Fi or plugged into its LAN ports) and must be able to reach the debug SSH service on the device - internet-side exploitation is not in scope per the CVSS AV:A vector. No prior authentication, user interaction, or non-default configuration is stated as required: the vulnerable debug SSH service and shared-credential behavior are properties of the affected firmware on Archer C64 v1.0. Exploitation is limited by the strength of the admin password (a high-entropy password makes brute force infeasible in practical timeframes), by whether the attacker can actually reach Layer 2 of the router, and by any deployment that has already disabled or firewalled the SSH service.

Signals are largely consistent and point to a meaningful but bounded risk. CVSS 4.0 (AV:A/AC:L/AT:N/PR:N/UI:N, VC:H/VI:H/VA:H) confirms adjacent-network, low-complexity, unauthenticated exploitation with high confidentiality, integrity, and availability impact - appropriate for a router takeover. The vulnerability is not listed in CISA KEV, no EPSS score was provided in the input, and no SSVC decision data is included, so widespread exploitation cannot be asserted. The 'Information Disclosure' tag understates the impact, which per the description is full administrative compromise. Practical risk is limited by the AV:A constraint (attacker must be on the local LAN or Wi-Fi, not the internet) and by the strength of the user-chosen admin password - a long/random password materially blunts the brute-force path even without rate-limiting. The debug SSH service being on by default versus opt-in is not stated in the available data and should be verified with TP-Link.

An attacker who has joined the same Wi-Fi network as the router - for example, a guest, a neighbor on an open or weakly-keyed SSID, or a malware-compromised host on the LAN - connects to the router's debug SSH port and runs an automated password-guessing tool against the admin account. Because no lockout or rate-limit is enforced, they iterate through a wordlist or credential-stuffing list until the shared web/SSH password is recovered, then log into the admin interface (or directly into the SSH shell) to alter DNS settings, pivot into the internal network, or persist on the device. No public exploit identified at time of analysis, but the attack only requires off-the-shelf SSH brute-force tooling.