VCSEC TPMS integer-overflow remote code execution

1. Summary

The Vehicle Controller Secondary (VCSEC) security/immobilizer module in the Tesla Model 3 fails to validate a length/offset field (startIndex) inside a TPMS sensor’s X.509 certificate response during wireless sensor enrollment [1][4]. A negative value passed through a signed-to-unsigned conversion becomes an enormous unsigned write offset, producing an out-of-bounds write that overwrites an adjacent function pointer [4][6]. By impersonating a tire-pressure sensor over the vehicle’s RF/BLE channel, an unauthenticated attacker within adjacent range can achieve code execution on VCSEC and, because that module bridges the CAN bus, inject arbitrary CAN traffic against the vehicle’s security and access functions [1][4]. The concrete downstream consequences of that CAN access are treated in §6.

2. Affected products & versions

Note: sources [1][2] describe the vulnerable window as “up to (excluding) 2024.14” and name 2024.8 as a known-affected build. They do not assert that builds below 2024.8 are unaffected, so no lower bound should be inferred.

3. The vulnerability in detail

The defect lives in the VCSEC module of the Tesla Model 3 — the electronic control unit responsible for vehicle security functions including the immobilizer and door-lock/access logic, and which is wired onto the vehicle’s internal CAN bus [1][4]. Specifically, the flaw is in VCSEC’s handling of a TPMS (Tire Pressure Monitoring System) sensor enrollment, during which the module and the sensor perform an X.509 certificate exchange over the wireless (BLE/RF) channel [1][3][4]. TPMS sensors are trusted, safety-relevant perception inputs: the vehicle expects to periodically re-learn and authenticate them, and it is precisely this trusted, automated re-learn path that the attacker abuses.

The root cause is an unvalidated startIndex field in the certificate response message [1][4]. When VCSEC parses the sensor’s certificate response, it uses this field as an offset/index into a buffer without bounds-checking or sign-checking it. The field is treated as unsigned, but an attacker can supply a negative value. Through the signed-to-unsigned conversion (or equivalent integer wraparound), that negative value becomes a very large unsigned number [4][6]. This is a textbook CWE-190 (Integer Overflow or Wraparound): an arithmetic conversion the developer assumed would stay in a small positive range silently produces a value far outside the intended bounds [2]. VCSEC then uses that corrupted value as a write offset, and the result is an out-of-bounds write that lands on memory adjacent to the certificate buffer — specifically, over a function pointer [4][6].

To make the offset arithmetic concrete: a field intended to index a few bytes into a certificate buffer is read as a signed integer at the wire but consumed as an unsigned offset by the write path. A small negative value such as -1 therefore does not index one byte before the buffer as a signed reading would suggest; instead, reinterpreted as unsigned, it becomes a near-maximal offset that wraps VCSEC’s pointer arithmetic to a location the attacker can position relative to the certificate buffer. Because the same attacker-supplied bytes that carry the certificate payload also carry the malicious startIndex, the write destination and the written data are both under attacker control — the two ingredients a memory-corruption exploit needs. The simulated proof-of-vulnerability models exactly this shape: a negative startIndex in a BLE message steering a memcpy so that it overwrites a function pointer positioned immediately before a 1024-byte certificate buffer [6]. (The 1024-byte figure and the memcpy primitive are the PoV’s simulation choices, not confirmed production-firmware internals.)

That single out-of-bounds write is the pivot from a memory bug to full code execution, and the reason it succeeds cleanly is a stack of missing platform mitigations on VCSEC [4]. VCSEC runs without ASLR (so the attacker knows where things live), without an MMU/MPU (so there is no memory-region enforcement), and with read-write-execute memory sections (so attacker-written bytes can be executed directly) [4]. In a hardened target, overwriting a function pointer with attacker-controlled data would still face address randomization and non-executable memory; here, none of those defenses exist, so overwriting the function pointer and then getting it invoked hands the attacker native code execution on the security module [4][6]. Each missing mitigation removes one link that would normally break the chain: ASLR would deny the attacker a known target address; an MMU/MPU would trap the out-of-bounds write before it landed; and non-executable memory (W^X) would stop the redirected pointer from executing attacker bytes. All three being absent is what turns a single parse-time offset error into reliable code execution.

The trigger is what makes this dangerous rather than academic: it is zero-click. TPMS “auto-learn” causes the vehicle to automatically re-enroll sensors under normal driving conditions — reported to occur after roughly 90 seconds of runtime and above about 25 kph [4]. An attacker does not need to induce any user action; they impersonate a TPMS sensor over the RF/BLE channel, wait for (or provoke) the auto-learn resync, and inject the malicious certificate response with the negative startIndex [3][4]. The preconditions are therefore modest in kind but demanding in skill: RF/BLE adjacency to the target vehicle, no authentication or credentials required, vulnerable firmware in the up-to-<2024.14 window (with 2024.8 confirmed affected), and a high-complexity reliable memory-corruption exploit against the specific VCSEC memory layout [1][4].

Putting the chain together end to end [4]: (1) the attacker gains RF/BLE adjacency and impersonates a TPMS sensor; (2) the vehicle enters zero-click auto-learn enrollment during normal driving; (3) the attacker sends a certificate response carrying an unvalidated negative startIndex; (4) VCSEC performs an out-of-bounds write, treating the value as an unsigned offset; (5) the write overwrites the function pointer adjacent to the certificate buffer; (6) with no ASLR/MMU/MPU and RWX memory, the corrupted pointer yields code execution inside VCSEC; (7) from VCSEC — which bridges the CAN bus — the attacker can emit arbitrary CAN messages to the vehicle’s security and access controllers [1][4]. The specific vehicle-level effects of that CAN access are analyzed in §6.

The technique was developed and demonstrated live by Synacktiv at Pwn2Own Automotive 2024 and detailed at Hexacon 2024 [3][7]. A public, educational proof-of-vulnerability (GitHub shirabo/cve-2025-2082-POV) simulates the signed-to-unsigned bug and models the function-pointer overwrite via memcpy against a 1024-byte certificate buffer — it illustrates the memory-layout mechanism but is explicitly not a real-vehicle exploit [6].

4. Discovery & timeline

The vulnerability was discovered by Synacktiv researchers Thomas Imbert, Vincent Dehors, and David Berard, who demonstrated it against a Tesla Model 3 at Pwn2Own Automotive 2024 and presented the full technical chain at Hexacon 2024 [1][3]. It was reported through Trend Micro’s Zero Day Initiative and tracked as ZDI-25-265 [1]. Tesla was notified on 2024-03-28, and the ZDI advisory was published on 2025-04-30 [1]. Per the ZDI advisory, the fix shipped in Tesla firmware 2024.14 [1]; NVD corroborates the vulnerable window only implicitly, listing versions “up to (excluding) 2024.14” without naming a fixed build [2].

5. Technical reference

• CVE: CVE-2025-2082 [1][2]
• ZDI advisory: ZDI-25-265 [1]; GitHub advisory: GHSA-h982-967r-m89p [5]
• CWE: CWE-190 — Integer Overflow or Wraparound [2]
• CVSS 3.0: 7.5, vector AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H [1][2][5]. Key metrics in context: AV:A (Adjacent) — exploitation requires RF/BLE proximity, not internet reach; AC:H (High) — a reliable memory-corruption exploit against the specific VCSEC layout is non-trivial; PR:N / UI:N — no credentials and no user interaction (the zero-click auto-learn path); S:U (Unchanged scope) in the CVSS model despite the cross-domain RF-to-CAN reality; C:H/I:H/A:H — full compromise of the module with high impact to confidentiality, integrity, and availability.
• Code/commit refs: no vendor source/commit is public. The only public code artifact is the simulated PoV shirabo/cve-2025-2082-POV modeling the negative-startIndex function-pointer overwrite against a 1024-byte buffer [6].

6. Consequence & CFSE path analysis

Real-world consequence: an attacker standing near a moving or recently-started Model 3 on vulnerable firmware, with no keys and no user cooperation, can run code on the car’s security module and then speak on the CAN bus as a trusted controller — unlocking doors, disabling the immobilizer, and interfering with vehicle startup. In practical terms this is a theft and physical-tamper primitive delivered through a tire-pressure sensor [4][7].

Why the CFSE Path Score diverges from CVSS: CVSS scores this 7.5 (“High”) and, crucially, marks scope Unchanged and treats it as a single technical-impact tuple on one component. CFSE instead follows the consequence across trust domains — from a manipulated perception input, through code execution on a security controller, to physical actuation on the CAN bus — which is exactly the cross-domain bridge CVSS’s Scope:Unchanged flattens away. That reframing is what pushes the path verdict to CRITICAL.

CFSE consequence bands and verdict:

• Verdict: CRITICAL.
• Dominant path — PERCEPTION_TO_ACTION (CRITICAL): manipulated TPMS certificate/sensor messages enter the vehicle’s trusted perception channel (safety-relevant sensor-trust input, DP:4) and, via an adjacent-RF integer-overflow exploit against the VCSEC security/immobilizer controller (AT:3, EC:2), drive physical actuation of immobilizer/lock state and bridge onto the CAN bus (CH:4, PH:3).
• Supporting path — DEVICE_CONTROL_SAFETY (HIGH): the same cross-domain chain (RF sensor input → code execution on the security module → CAN commands) can disable protective functions or unlock the vehicle, reducing safety margins and enabling theft or interference with controls.
• Shared factors: exposure EX:2 (adjacent RF range, no credentials, but a specialist reproducible memory-corruption exploit); fleet-wide reuse of a portable firmware exploit (SR:4) tempered by per-vehicle proximity delivery (SX:2); OTA fleet-update recovery (OR:4); reproduced live at Pwn2Own Automotive 2024 (EV:3); patch available.
• Net: path_verdict = CRITICAL, driven by the dominant perception-to-action path, with no cap or systemic uplift applied.

7. Remediation & mitigations

• Primary fix: update affected Model 3 vehicles to firmware 2024.14 or later via Tesla’s OTA channel [1]. OTA distribution means fleet recovery is fast and does not require owner action beyond installing the pushed update. (The 2024.14 fixed build is stated by the ZDI advisory [1]; NVD lists the vulnerable window as “up to (excluding) 2024.14” but does not itself name a fixed version [2].)
• Root-cause hardening (vendor-side, specific to this bug): validate the startIndex/offset and length fields of the TPMS certificate response before they reach any write path — reject negative values and any offset+length that exceeds the certificate buffer, and parse the field with an explicit width/signedness so the signed-to-unsigned conversion can no longer manufacture an out-of-bounds offset [4][6]. Bounds-check the destination of the enrollment memcpy/write against the actual buffer extent rather than trusting the sensor-supplied index [6].
• Platform hardening on VCSEC (the enabling weaknesses): introduce ASLR so a function-pointer overwrite cannot rely on known addresses; enforce memory regions via an MMU/MPU so the out-of-bounds write faults instead of landing silently; and remove read-write-execute (enforce W^X) so attacker-written bytes in the certificate buffer are never directly executable [4]. Each of these independently breaks the §3 exploitation chain even if the parse bug recurs.
• Sensor-enrollment trust hardening: because the entry is a legitimate-looking TPMS auto-learn over RF/BLE, treat sensor-supplied certificate fields as untrusted input throughout the enrollment state machine (length/offset validation, fixed-size framing), rather than assuming a well-formed peer [3][4].
• Note on scope of detection: because the trigger is a legitimate-looking TPMS auto-learn enrollment over RF/BLE, the meaningful defense is the firmware-level input validation and memory hardening above; there is no generic network control that applies to this adjacent-RF sensor path.

8. Sources

[1] ZDI-25-265: Tesla Model 3 VCSEC Integer Overflow Remote Code Execution Vulnerability — Zero Day Initiative (Trend Micro) — https://www.zerodayinitiative.com/advisories/ZDI-25-265/ — Coordinating-CNA advisory; authoritative CVSS vector, TPMS cert-response root cause, RCE-to-CAN impact, discovery credit, disclosure timeline, and fix version (firmware 2024.14). Credibility: primary advisory.

[2] NVD — CVE-2025-2082 — NIST National Vulnerability Database — https://nvd.nist.gov/vuln/detail/CVE-2025-2082 — Canonical CVE record confirming CWE-190, the CVSS 3.0 7.5 vector, adjacent/unauthenticated description, and affected firmware window (“up to (excluding) 2024.14”, 2024.8 known-affected; does not itself name a fixed build). Credibility: primary advisory.

[3] 0-click RCE on Tesla Model 3 through TPMS Sensors (Hexacon 2024) — Synacktiv — https://www.synacktiv.com/sites/default/files/2024-10/hexacon_0_click_rce_on_tesla_model_3_through_tpms_sensors_light.pdf — Discovering team’s own slide deck; primary technical writeup of the enrollment/X.509 exchange, negative-startIndex OOB write, function-pointer overwrite, and auto-learn trigger. Credibility: researcher-primary (binary PDF, not auto-extractable).

[4] Under Pressure: Exploring a Zero-Click RCE Vulnerability in Tesla’s TPMS — VicOne — https://vicone.com/blog/under-pressure-exploring-a-zero-click-rce-vulnerability-in-teslas-tpms/ — Deepest secondary analysis; explains the auto-learn zero-click mechanism (>25 kph / ~90s), the unvalidated negative startIndex OOB write, the enabling platform weaknesses (no ASLR/MMU/MPU, RWX memory), and CAN-bus impact. Credibility: reputable press.

[5] Tesla Model 3 VCSEC Integer Overflow RCE — GitHub Advisory GHSA-h982-967r-m89p — GitHub Advisory Database — https://github.com/advisories/GHSA-h982-967r-m89p — Independent aggregator record corroborating the CVSS, CWE-190, and unauthenticated description. Credibility: primary advisory.

[6] shirabo/cve-2025-2082-POV — GitHub (independent contributor) — https://github.com/shirabo/cve-2025-2082-POV — Public simulated proof-of-vulnerability modeling the signed-to-unsigned bug and negative startIndex overwriting a function pointer before a 1024-byte certificate buffer during memcpy; illustrative, not firmware-ready. Credibility: community PoC.

[7] Tesla Model 3’s TPMS Breach Unveils Security Flaw — Cybellum — https://cybellum.com/blog/breach-in-tesla-model-3-tpms-unveils-serious-security-flaw/ — Independent industry analysis of the TPMS→VCSEC→CAN attack path and remote-unlock consequence at Pwn2Own 2024. Credibility: reputable press.