Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain physical custody of device
-
DeliveryDisassemble and restore severed debug traces
-
ExploitInterrupt boot and alter boot parameters
-
ExecutionEnter non-standard init path
-
ImpactObtain unauthenticated root shell at startup
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture On-chip debug access control
|
| Exploitation Conditions | Exploitation requires full physical possession and disassembly of the device, plus hardware-level work: the manufacturing-severed debug traces must be physically restored (resoldered/bridged) because the production debug interface is not logically disabled at firmware or chip level and the bootloader is not locked. The attacker must then interrupt the boot process over that restored interface and manipulate boot parameters to reach a non-standard initialization path that exposes an unauthenticated root shell. Limiting factors: no remote or network path exists (AV:P), no over-the-air or software-only exploitation is possible, and success depends on hardware rework skill and tools - these constraints sharply reduce realistic risk outside of untrusted-physical-custody threat models. |
| Impact | This is a genuinely low-to-moderate real-world risk despite full confidentiality/integrity/availability impact, because the attack vector is physical and gated behind demanding preconditions. The CVSS 4.0 vector (AV:P/AC:L/AT:P/PR:N/UI:N) correctly reflects that no credentials or user interaction are needed once the attacker has the device in hand, but AV:P plus AT:P (a specific attack requirement) means the attacker must physically possess, disassemble, and modify the hardware - restoring debug traces that were deliberately severed during manufacturing. There is no EPSS score provided, no CISA KEV listing, and no public exploit identified, so there is no evidence of scalable or remote exploitation; the 5.4 base score is consistent with a high-impact-but-hard-to-reach local hardware flaw rather than a mass-exploitable network vulnerability. The signals are internally consistent (no conflict between vector and description - both indicate physical/local access), so this should be triaged as a hardware supply-chain / device-tampering concern rather than a fleet-wide emergency. Priority rises only for threat models involving untrusted physical custody (resale, loss, theft, evil-maid, or hostile lab access). |
| Exploit ScenarioDerived | An attacker who gains temporary physical custody of a Kasa EC70 v4 or EC71 v4 device (e.g., a returned/resold unit, or a device accessed in a hostile environment) disassembles it, resolders or bridges the manufacturing-severed debug traces, and interrupts the boot sequence over the restored interface. By manipulating boot parameters they force a non-standard initialization path that drops an unauthenticated root shell during startup, giving full control of the device. No public exploit code is identified at time of analysis, so this currently requires attacker-developed hardware tooling and know-how. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 01, 2026
Physical attackers who can obtain, disassemble and hardware-modify a TP-Link Kasa EC70 v4 or EC71 v4 smart plug can restore the manufacturing-severed debug traces, interrupt the boot process and manipulate boot parameters to reach a non-standard initialization path that spawns an unauthenticated root shell during startup, giving full root-level control over the device (high confidentiality, integrity and availability impact to the device itself). The root cause is improper access control on the on-chip debug interface (CWE-1191): the production debug interface is not logically disabled at the firmware or chip level and the bootloader is not locked, so the physical cut of the debug traces is the only barrier. The attacker path is purely physical (CVSS 4.0 AV:P/AC:L/AT:P, assessed as CVSS 3.1 AV:P/AC:H), with no remote or over-the-air vector, and exploitation demands disassembly, trace rework (resoldering/bridging) and boot-timing manipulation; no public exploit code has been identified at time of analysis and the CVE is not listed in CISA KEV, while vendor firmware updates are available per the TP-Link release notes.
RemediationAI
TP-Link has released firmware for the EC70 v4 and EC71 v4 that addresses this hardening gap - check and apply the latest firmware from the vendor release notes at https://www.tp-link.com/us/support/download/ec70/v4/#Firmware-Release-Notes and https://www.tp-link.com/us/support/download/ec71/v4/#Firmware-Release-Notes, and follow the guidance in https://www.tp-link.com/us/support/faq/5324/ (patch available per vendor advisory; no single fixed version number is published in the data supplied here, so confirm the current build on the download pages). Note that because the debug interface is exposed at the bootloader/chip level, firmware updates may only partially mitigate unless they also lock the bootloader and logically disable the debug path - verify with the vendor which build enforces this. No configuration workaround fully removes the risk; the effective compensating controls are physical: keep the plugs in trusted, access-controlled custody, use tamper-evident seals or labels so trace rework is detectable, audit second-hand or returned units before deployment, and treat any device that has been out of custody as potentially compromised (the trade-off is that seals and audits add logistics overhead and can be defeated by a determined attacker, while simply not deploying these models in public or untrusted spaces eliminates the threat entirely at the cost of replacing them with physically hardened alternatives). Because exploitation gives root without authentication, any device suspected of trace rework should be factory-reset, re-flashed with the patched firmware, or retired, and its credentials and any linked cloud account should be rotated.
Affected VersionsENISA
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability class is CWE-1191 (On-Chip Debug and Test Interface With Improper Access Control), and it affects the hardware debug path of the Kasa EC70 v4 and EC71 v4 smart plugs (CPE cpe:2.3:a:tp-link_systems_inc.:kasa_ec70_v4 and cpe:2.3:a:tp-link_systems_inc.:kasa_ec71_v4, all firmware versions). During manufacturing the UART/JTAG-class debug traces are physically severed, but neither the SoC/chip-level debug logic nor the bootloader enforces a logical disable, and the bootloader is left unlocked. That means the only control protecting the debug interface is a physical one that can be reversed with basic electronics rework. An attacker with the device in hand can resolder or bridge the severed pads, attach to the debug interface, interrupt the normal boot sequence and pass modified boot parameters that steer the device into a non-standard initialization path; that path leaves an unauthenticated root shell exposed during startup, granting root-level command access. Because the exposure occurs pre-/during initialization rather than over a network service, there is no remote exploitation path and no software-only or over-the-air trigger - the practical prerequisite is physical custody plus hardware rework skill and tooling, which is why the assessed CVSS 3.1 vector (AV:P/AC:H) is more conservative than the vendor's CVSS 4.0 AV:P/AC:L rating. The impact is scoped to the affected device (S:U, SC:N/SI:N/SA:N) rather than to connected networks.
Know when Kasa Ec70 V4 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:P/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Physical access only (AV:P); AC:H reflects the specialized hardware rework of restoring severed debug traces; no auth or interaction needed (PR:N/UI:N); full root yields C:H/I:H/A:H.
Primary rating from Vendor (TPLink).
CVSS VectorVendor: TPLink
DescriptionCVE.org
Kasa EC70 v4 and EC71 v4 do not logically disable the production debug interface at the firmware or chip level and do not lock the bootloader. Although the debug traces are physically severed during manufacturing, an attacker with physical access can restore the connection, interrupt the boot process, and manipulate boot parameters to enter a non-standard initialization path that exposes an unauthenticated root shell during startup.
Successful exploitation may allow an attacker with physical access to obtain root-level command access during device startup, resulting in loss of confidentiality, integrity, and availability for the affected device. Exploitation requires device disassembly, restoration of the severed debug connection, and manipulation of the boot process.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
More in Kasa Ec70 V4
View allUse of a hard-coded, device-shared cryptographic private key in TP-Link Kasa EC71 v4 and EC70 v4 camera firmware lets an
Unauthenticated information disclosure in TP-Link Kasa EC70 v4 and EC71 v4 exposes sensitive geolocation data to any att
EUVD-2026-91060
GHSA-6p9x-mrgq-g8cr
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB