By Jason Yuan (Engineer, Automotive)
Although it may appear to be a simple electric vehicle (EV) charger, the Tesla Wall Connector can be fully compromised right at its charging connector. At Pwn2Own Automotive 2025, the Synacktiv team did exactly that and uncovered CVE-2025-8321 in the process. This vulnerability chained a diagnostic access, a firmware downgrade, and a buffer overflow to achieve full remote code execution (RCE).
In this blog entry, we walk through the vulnerability’s exploit chain and discuss its broader implications not only for automotive cybersecurity but also for the electric vehicle supply equipment (EVSE) industry.
Tesla Wall Connector: a brief overview
As EV adoption is soaring, the humble home charger now sits between household wiring and a high-voltage battery. A wall-mounted AC charger, such as Tesla’s third-generation Wall Connector, does far more than close a relay. Through its Proximity and Control Pilot lines, it negotiates safe current limits, supervises the state of charge, and increasingly supports higher-level protocols that allow utility companies to limit charging load or even draw energy back from the vehicle’s battery.
Most manufacturers enable this vehicle-to-charger communication by layering power line communication (PLC) and the ISO 15118 protocol stack onto the Control Pilot conductor. Tesla, however, took a different approach by repurposing the same wire into a 33.3 kbps single-wire Controller Area Network (CAN) bus, a design choice carried over from the original Model S. After the initial handshake, standard CAN frames begin to flow, enabling the vehicle and charger to exchange firmware, configuration data, and telemetry without requiring additional communication hardware.
Single-wire CAN is not a vulnerability in itself. Still, the fact that it spans the entire charging cable means anyone holding the EV charger’s connector is physically connected to a private diagnostic network. This extended reach effectively places the Tesla Wall Connector within the vehicle’s security boundary, a position that justifies auditing its firmware as rigorously as any in-vehicle electronic control unit (ECU).
Building the exploit chain
Replicating Synacktiv’s exploit requires equal parts hardware improvisation and protocol detective work. The first step is simply to observe: connect a high impedance logic analyzer to the Control Pilot line, let a vehicle and charger negotiate as usual, and monitor the signal. As soon as the charging is authorized, the line drops its 1 kHz pulse wave modulation (PWM) signal and is replaced by a 33.3 kbps single-wire CAN stream. Among the traffic, a tell-tale arbitration ID appears at regular intervals, repeating every 100 milliseconds.
With the traffic pattern known, the next step is persuasion. A microcontroller and a handful of resistors must replicate the Type 2 voltage sequence convincingly enough for the Wall Connector to believe it’s communicating with a real vehicle, even though the logic is being run from a bench setup. The same microcontroller also maintains the CAN link by scheduling the 100-ms heartbeat, ensuring the connection never goes idle.
To communicate over the Control Pilot conductor, a standard USB-to-CAN adapter first undergoes a hardware modification. Its high-speed CAN transceiver is replaced with an NCV7356 device, and the firmware is retimed for 33 kbps single-wire CAN. The modified adapter connects to a small controller, such as a Raspberry Pi. This same controller also drives a discrete circuit that emulates the IEC 61851 handshake. The circuit delivers the familiar 1 kHz PWM signal, convinces the Wall Connector that a vehicle is present, and then hands off control of the wire to the single-wire CAN node.
Once the 100-ms heartbeat is active, the host captures the charger’s seed-key challenge. It observes that each key is derived by simply XORing the seed with 0x35, replies with the correct value, and enters Unified Diagnostic Service (UDS) extended diagnostic mode. At this point, flash operations are permitted, allowing the attacker to install an older firmware version with a built-in debug shell.
Figure 1. Attack chain used against the Tesla Wall Connector to achieve remote code execution
Mapping the exploit chain to the Automotive Threat Matrix
Synacktiv’s exploit highlights three key vulnerabilities in the Tesla Wall Connector that link a grasped charging handle to full RCE.
- Handle-as-attack-vector. Anyone with physical access to the charging handle, such as in public parking lots, hotel valet areas, or shared apartment garages, can inject Single-Wire CAN traffic. This is functionally equivalent to plugging into an unprotected on-board diagnostics (OBD-II) port with UDS left wide open.
- Home network bridge. The charger stores Wi-Fi credentials in plain text. An attacker can extract these over CAN/UDS and pivot from the vehicle side to the owner’s local area network (LAN).
- Lack of memory safety. The FreeRTOS debug shell runs in readable, writable, and executable (RWX) memory with no data execution prevention (DEP) or address space layout randomization (ASLR). Its input filter rejects only \r, leaving it vulnerable to a single buffer overflow that is sufficient to achieve RCE.
To better understand the scope of the attack, we mapped Synacktiv’s exploit methodology to the Automotive Threat Matrix (ATM). This exercise demonstrates how the ATM framework can be used to identify, classify, and mitigate cybersecurity risks in automotive systems. Our mapping also underscores the structured nature of automotive cybersecurity analysis and emphasizes the need for systematic defenses aligned with recognized threat models.
| ATM Technique | ATM ID | Manifestation in the Wall Connector exploit |
|---|---|---|
| Unintended Vehicle Network Message | ATM-T0071 | Custom simulator on the Control Pilot line injects Single-Wire CAN/UDS traffic. |
| ECU Credential Dumping | ATM-T0039 | ReadDataByIdentifer leaks the charger’s setup service set identifier (SSID) and pre-shared key (PSK) after downgrade. |
| Reprogram ECU for Lateral Movement | ATM-T0054 | Legacy firmware 0.8.58 is flashed to the passive slot, opening the debug shell. |
| Bypass UDS Security Access | ATM-T0033 | XOR-0x35 routine responds to the fixed 16-byte Security-Access challenge. |
| Local Function | ATM-T0069 | Root on the AW-CU300 allows an attacker to toggle relays and LEDs. |
| Remote Services | ATM-T0053 | An exposed Telnet shell provides a network-reachable interface for code execution. |
Trend Zero Day Initiative (ZDI), VicOne’s co-host for Pwn2Own Automotive and partner in vulnerability discovery and disclosure, promptly reported the vulnerability to Tesla. According to Synacktiv’s blog, Tesla has since addressed the issue by implementing an anti-downgrade mechanism that blocks the firmware rollback used in the exploit. Trend ZDI also confirmed this in itslatest advisory, stating that the flaw has been fixed in Firmware Version 24.44.3.
Chargers as a Cross-Domain Threat
A compromised EV charger poses a threat to both traditional network security and automotive security. Once connected to a home or enterprise LAN with valid credentials, it can bypass perimeter defenses and enable lateral movement from an unexpected entry point.
At the same time, it maintains direct access to the vehicle through single-wire CAN, capable of injecting spoofed messages before any in-vehicle security layers are engaged. This convergence makes the charger a dual-risk asset – one that bridges two critical domains, and whose compromise can impact both.
As EV adoption continues, chargers can no longer be treated as passive power devices. They must be protected like any other connected endpoint: with firmware validation, service isolation, and continuous monitoring to prevent compromise from escalating across domains.
A background on coordinated disclosure timelines
The timeline of public vulnerability disclosures can seem unclear to many. For example, there is often a delay between Trend ZDI’s announcement that a team has successfully hacked or “pwned” a device at a Pwn2Own event and the subsequent publication of the techniques used in the attack. This delay is part of the coordinated vulnerability disclosure (CVD) process, which aims to manage zero-day vulnerabilities responsibly.
In the 1990s, only a small number of hackers actively searched for vulnerabilities, and many vendors were unprepared to handle them. Concerns arose from both sides: “Are hackers submitting vulnerabilities in exchange for benefits?” and “Will these vulnerabilities actually be fixed, or will the effort be wasted?” The compromise became clear: Hackers would first submit vulnerabilities to vendors, who would then release a patch and publicly acknowledge the researchers for their discovery.
According to Trend ZDI’s disclosure policy, a submitted vulnerability is disclosed when a patch becomes available — or after a certain period if the vendor remains unresponsive. This approach either addresses the vulnerability or informs the public about an unresolved issue, reducing the likelihood of exploitation. This explains the time gap between initial discovery and full public disclosure.
