Tesla TCU CVE-2025-34251

Requires physical access to the vehicle's externally exposed USB port, which connects to the privileged adbd (running as root) on TCU firmware prior to v2025.14. No authentication is required (adbd auth/lockdown is bypassed) and no user interaction is needed, but exploitation depends on the specific affected firmware and on adb push/pull/forward remaining enabled under the ineffective 'lockdown' state. Exploitation is fundamentally gated by in-person physical access to the device; it cannot be performed remotely or at scale, which is the primary limiting factor for defenders.

Signals are consistent and point to a serious-but-access-constrained issue. The CVSS 4.0 vector (AV:P/AC:L/AT:N/PR:N/UI:N) with full high impact on both the vulnerable and subsequent systems (VC/VI/VA:H, SC/SI/SA:H) yields an 8.6 base score, driven by complete root compromise of the Telematics Control Unit once access is obtained. The dominant limiting factor is AV:P - physical access to the externally exposed USB port is mandatory, which sharply narrows real-world exploitability versus a network-reachable flaw. This is corroborated by the EPSS score of 0.45% (37th percentile), which is low and consistent with a physical-access vulnerability that cannot be exploited at internet scale. The vulnerability is NOT in CISA KEV and there is no confirmed public exploit, so this is not evidence of active, widespread exploitation. In short: high technical impact (full root, auth bypass) but a high access bar. Priority is elevated for high-value/targeted threat models (vehicle theft, forensic/physical attackers, supply-chain or valet/service scenarios) but low for commodity remote-exploitation concerns. Note a data nuance: the input Tags include 'Google' as an apparent vendor, but the affected product is Tesla's TCU - the Android/ADB lineage explains the tag but it mislabels the vendor; verify tagging.

An attacker with physical access to a Tesla vehicle connects to the externally exposed USB port, which reaches the root-level adbd service. Despite the 'lockdown' that blocks adb shell, the attacker uses the still-permitted adb push to drop a malicious script, then overwrites the kernel's uevent_helper or /proc/sys/kernel/hotplug entry via ADB so the script executes as root on the next hotplug event. No public exploit code is identified at time of analysis, though a detailed NCC Group technical advisory describes the technique.