In January 2025, Synacktiv (David Berard) won Pwn2Own Automotive 2025 (Tokyo) against the Tesla Wall Connector Gen 3 (AW-CU300 connectivity card, Marvell 88MW300 / ARM Cortex-M4, paired with an STM32 microcontroller for metering/relay control, the two chips communicating over UART using Protocol Buffers) using an attack surface that had never been demonstrated publicly: the vehicle-side charging connector itself. The Wall Connector's Control Pilot (CP) line, once a vehicle pulls the PWM signal to +6V/-12V to indicate charging readiness, carries a non-standard protocol identified as Single-Wire CAN (SWCAN) at 33.3 kbps, over which Tesla implements UDS (Unified Diagnostic Services) on CAN identifier 0x604. Opening a diagnostic session (UDS session type 2) requires passing UDS Security Access Level 5, gated by a fixed 16-byte challenge whose expected response is each challenge byte XOR'ed with the static value 0x35 — a trivially reversible, hardcoded challenge-response scheme rather than genuine cryptographic authentication. Once authenticated, the researchers used UDS services RequestDownload (0x34), TransferData (0x36), and RequestTransferExit (0x37) to push firmware images, and Routine Control identifiers 0xFF00 (erase/prepare the passive slot), 0x201 (validate and switch/activate firmware), 0x202 (reboot), and 0x102 (mark a slot 'settable via UDS', value 0x0E) to drive the two-slot A/B update state machine.

That original chain — later assigned CVE-2025-8321 (CVSS 3.0/3.1 6.8, vector AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-1328 Vulnerability from Insufficient/Incomplete Design, related CWE-696 Incorrect Behavior Order) — abused the complete absence of any anti-downgrade protection in the UDS updater: the researchers pushed a legacy firmware image (version 0.8.58, recovered from 2021-era Tesla infotainment-system dumps) that still exposed debug-only UDS identifiers (0x501 for the Wi-Fi setup-AP pre-shared key, 0xf040 for the device MAC address) and an active TCP debug shell reachable over the device's own Wi-Fi setup access point. That debug shell contained a global buffer overflow in its command-line parser: arguments were stored in a fixed 16-entry global array with no bounds check, so the 17th-and-later argument pointers wrote past the array into an adjacent command-handler table of function pointers, letting the attacker redirect execution to attacker-controlled memory and achieve arbitrary code execution — trivially reliable because the firmware maps every memory region RWX (readable, writable, and executable, i.e. no W^X enforcement). The team built a custom rig (a Raspberry Pi driving CP/PP simulation relays, plus a FYSETC UCAN USB-CAN adapter modified with an NCV7356 SWCAN transceiver, driven by python-can/udsoncan scripts) and completed the live exploit in roughly 18 minutes — the low 33.3 kbps SWCAN bandwidth being the main bottleneck — for $45,000 and 7 Master of Pwn points, on the first attempt.

Tesla's remediation (firmware 24.44.3, first seen in the field around 28 February 2025, which also added WPA3 support) introduced a new updater routine, `check_image_and_antidowngrade()`, which parses firmware-segment version tags (`VRSN` for the version descriptor, `VRS2` marking presence of the ratchet field) and calls `verify_firmware_segments_platform()` to compare the incoming image's ratchet value against a ratchet counter persisted on-device in the Persistent Storage Manager (PSM); the check accepts only `current_ratchet <= firmware_ratchet` and otherwise rejects with a logged 'Security ratchet downgrade prevented' message. This logic is invoked from `switch_to_new_firmware()`, itself triggered by UDS routine 0x201.

In the May 2026 Part 2 write-up this threat record documents, Berard shows the ratchet check was implemented in the wrong layer of the update state machine. UDS routine 0xFF00 (`prepare_passive_slot()`) selects and erases the *passive* firmware slot purely based on immutable boot flags (`g_boot_flags`) set at device startup — it neither knows nor cares what is currently staged there or whether a partition-table commit has already happened. Routine 0x201 is what actually writes the new partition layout (`part_write_layout()`, bumping the slot's `gen_level` generation counter) and is the *only* place the ratchet value is checked. Routine 0x202 simply triggers the reboot. The bypass sequence Berard demonstrates: (1) push a valid, ratchet-passing firmware image (e.g. the current 24.44.3) and call routine 0x201, which writes the partition table, checks the ratchet, and commits the slot as active-on-next-boot; (2) without rebooting, call routine 0xFF00 again — it calls `prepare_passive_slot()`/`part_erase()` on the same physical slot per the still-unchanged boot flags, erasing the just-validated firmware but leaving the already-committed partition table (and its bumped `gen_level`) untouched; (3) push the old vulnerable firmware (0.8.58, still RSA-signed by Tesla) into the now-empty slot via 0x34/0x36/0x37; (4) call routine 0x202 directly, skipping routine 0x201 entirely — and with it, the only code path that ever calls `verify_firmware_segments_platform()`. On boot, Tesla's second-stage bootloader (boot2) validates the `SBFH` magic header, a per-segment CRC32, and the RSA signature of whatever image sits in the slot with the highest `gen_level` in the partition table — all of which the legitimately-signed 0.8.58 image still passes — but boot2 never re-checks the PSM ratchet value itself. The device therefore boots the downgraded, debug-shell-exposed 0.8.58 image, fully re-opening the original Pwn2Own attack chain (Wi-Fi PSK/MAC disclosure via UDS, then the debug-shell buffer overflow) on a device that is otherwise fully patched, in roughly 30 minutes over SWCAN (versus 18 for the original chain, since two full firmware images must now be transferred over the bus). Because a compromised Wall Connector typically shares the same home or business network as other devices, the bypass restores a physical-access network-foothold primitive even against updated units. Synacktiv's stated recommended fixes are to enforce ratchet validation directly in the bootloader (not only the updater), to have routine 0xFF00 invalidate/reset the partition layout whenever it erases a slot, to force a reboot immediately after a successful 0x201 update rather than allowing further routine calls, and to reject new update sessions once 0x201 has succeeded. Tesla was notified and shipped a further silent OTA fix several months before the May 2026 publication; no CVE has been assigned to this specific bypass.