Tesla Gets Hacked at Pwn2Own Every Year. The Reason Every EV Owner Should Worry.

It’s not a Tesla problem. It’s a hardware problem — ECUs, CAN bus networks, charging ports, and the cybersecurity gaps baked into the silicon of every modern electric vehicle.

By Imran | Silicon to Software | Published May 2026

Note: This article documents publicly disclosed vulnerability research presented at sanctioned security competitions and peer-reviewed conferences. No exploit code, attack instructions, or methods are described.

It Took Under 30 Seconds

March 2024. Vancouver. A French cybersecurity firm, Synacktiv, approaches a brand-new, fully patched Tesla Model 3 at the Pwn2Own hacking competition. One integer overflow flaw in the car’s Electronic Control Unit (ECU). That’s it. According to the Zero Day Initiative’s live event log, they gained Vehicle (VEH) CAN BUS Control in what BleepingComputer described as a matter of moments during the live demonstration.

They walked away with $200,000. And the car. Their second one — they won a Model 3 at Pwn2Own Vancouver 2023 too.

Quick context if you’re new to this: Pwn2Own is an annual hacking contest organized by Trend Micro’s Zero Day Initiative (ZDI). Researchers attack real, fully patched devices. They keep whatever they compromise. Every flaw gets reported directly to the vendor before anything goes public. Tesla shows up voluntarily. The cars are unmodified. There’s no handicap.

I think that’s the part people don’t sit with long enough. It’s not that Tesla got hacked once. It’s that Synacktiv has demonstrated a new exploit against Tesla hardware at multiple consecutive Pwn2Own competitions. Different attack surfaces every time. Same outcome: control.

Here’s the thing — this isn’t really a Tesla story.

Tesla is among the most software-connected EV platforms globally — and the most tested for that very reason. But what these researchers keep finding inside Tesla’s hardware? It exists, in some form, in every modern EV. Embedded cellular connectivity has become standard across most new EV platforms throughout the early 2020s — built in at the factory, not added as an option. The connected vehicle market has grown continuously over this period, and that direction hasn’t reversed.

We don’t talk about this. Not really. We argue about range. Charging networks. Battery degradation. But the hardware sitting between you and a potential attacker? Barely gets a mention.

That changes here.

Your Car Has 150 Computers

I’m going to skip the preamble and go straight to the part that broke my brain when I first read it: someone exploited a Tesla’s Tire Pressure Monitoring System (TPMS).

Same competition — Pwn2Own 2024. Same team. Per VicOne’s detailed technical analysis and Synacktiv’s own Hexacon 2024 presentation, researchers David Berard and Thomas Imbert discovered that a vulnerability in the TPMS sensor pairing process could allow malformed certificate responses to trigger an integer overflow in the Vehicle Controller Security (VCSEC) module. The VCSEC is not a peripheral module — per VicOne’s analysis, it controls door locks, the immobilizer, vehicle startup authorization, and critically, interfaces directly with the vehicle’s CAN bus to relay messages across subsystems. When exploited, an out-of-bounds write to the VCSEC’s heap enabled arbitrary code execution — zero-click, no user interaction required.

One technical factor that made this exploit work cleanly: per VicOne’s analysis, Tesla’s VCSEC module uses a memory configuration that is simultaneously readable, writable, and executable (RWX). That’s a serious misconfiguration. A standard secure memory design keeps writable and executable regions separate — when both are active, an attacker can inject code directly into memory and execute it without additional privilege escalation.

The attack runs over adjacent wireless interfaces associated with the VCSEC module’s communication stack. Per Synacktiv’s Hexacon 2024 presentation, the VCSEC uses Bluetooth Low Energy (BLE) and Ultra-Wideband (UWB) for the Tesla app and proximity authentication functions. An attacker needs to be within range of the wireless network. Not an over-the-internet attack.

On the other hand, maybe I’m wrong to call that reassuring. Parking garages exist. Valet lines exist. Charging queues exist. Proximity is achievable.

Your tires. Attack vector. Let that sit.

Okay — so why does any of this work structurally? Here’s what you need to understand.

A modern EV isn’t a car with a computer in it. It’s a computer with wheels. Most carry 70-150+ Electronic Control Units — each a dedicated embedded computer running a specific job: brakes, steering, airbags, thermal management, power conversion. That range is well documented across Bosch Corporation’s engineering literature and Aptiv’s ECU technical documentation.

The Protocol Nobody Thought to Secure

Every one of those ECUs communicates through the Controller Area Network, or CAN bus — a message-based protocol designed by Bosch in the 1980s for industrial and automotive applications. Per Dewesoft’s technical documentation on CAN bus architecture, it is “designed to allow the ECUs found in today’s cars to communicate with each other in a reliable, priority-driven fashion.”

Smart for its time. The problem? It was never designed for cybersecurity. Peer-reviewed automotive security research has consistently identified the absence of native message authentication and encryption in classic CAN bus protocols as a fundamental, widespread architectural weakness. Messages travel as plain text. An ECU cannot verify the origin of a message it receives. Modern architectures increasingly layer security controls above the bus — such as AUTOSAR Secure Onboard Communication (SecOC), gateway filtering, and message authentication codes — but these overlays add complexity and are far from universally deployed across the existing vehicle fleet. Most OEM cybersecurity engineering workflows now align with ISO/SAE 21434, the standard that defines how R155 compliance is actually implemented in practice.

In my experience on the PCB manufacturing side of this industry, this kind of legacy design debt is the hardest thing to fix. You can layer software over it. You cannot easily re-route a physical bus on hundreds of millions of vehicles already on the road.

The Attack Surfaces Nobody Is Talking About

How does an attacker actually get in? They don’t need your windows.

I’ve noticed that people assume physical access is the baseline requirement for serious automotive attacks. It’s not. Sometimes the easiest entry point is the one you use every week.

The charging port. In October 2024, researchers presented findings at Hardwear.io titled “Hacking EV charging stations via the charging cable.” Per BankInfoSecurity’s coverage of the presentation, researchers tested hardware from 13 manufacturers, 18 DC charging stations, and one AC unit. Half had exploitable vulnerabilities. Eight left SSH ports exposed. Others used the unsecured HTTP and MQTT protocols.

Researchers at PlaxidityX (formerly Argus Cyber Security) have documented two distinct attack paths through the charging interface. First, they discovered CVE-2024-37310 — an integer overflow in the V2G Transport Protocol (V2GTP) implementation of the EVerest open-source EV charging software stack. According to PlaxidityX’s published advisory, this vulnerability allows a remote attacker to overflow the charging station’s heap, potentially gaining arbitrary code execution on the charging station itself — compromising private keys, bypassing payment gates, and impersonating the station to backend systems. Second, and separately, PlaxidityX demonstrated that an attacker can impersonate a charger entirely — mimicking its digital signals at the charge port to inject malicious data into the vehicle’s internal network. These are two sides of the same threat surface: the charging infrastructure is vulnerable, and so is the vehicle’s trust in that infrastructure.

Not great.

When the Screen Becomes the Vulnerability

The infotainment system. In August 2023, researchers from the Technische Universität Berlin (TU Berlin) — Christian Werling, Niclas Kühnapfel, Hans Niklas Jacob, and independent researcher Oleg Drokin — presented at Black Hat USA 2023. Per their Black Hat briefing and BleepingComputer’s coverage, they used a voltage-fault injection attack against Tesla’s AMD Secure Processor (ASP), which serves as the root of trust for Tesla’s MCU-Z infotainment system. Important constraint: this attack requires physical access to the vehicle — per The Register’s coverage, the researchers soldered wires directly to the infotainment and connectivity ECU to manipulate power delivery at precisely the right moment. Once past the ASP, they gained root access to the Linux-based infotainment OS and could run arbitrary software. They activated features such as Acceleration Boost and Full Self-Driving Beta without paying.

The feature unlock is the less alarming part. What matters is the path they used. The same technique could expose hardware-bound RSA keys Tesla uses to authenticate each vehicle, decrypt NVMe storage, and access private user data. The researchers noted the exploit is “unpatchable” via software because the flaw lives in hardware.

I know what you’re thinking — lab researchers, controlled conditions. Fair point. But controlled research becomes a real-world playbook faster than most people expect.

Why EVs Face a Broader Attack Surface Than Most Connected Devices

I’ve found that people assume newer technology means better security. It doesn’t. Not automatically. Here’s why EVs have it harder than most connected devices.

Scale of connectivity. Your EV is talking to a lot of things at once — charging networks, OEM cloud servers, OTA update pipelines, V2X systems, your phone. Every single one of those connections is a door. Analysts at Upstream Security and VicOne keep flagging the same two culprits: telematics control units (TCUs) and infotainment systems. Most exposed. Historically, the least protected.

Supply chain chaos. One EV pulls ECUs, chips, sensors, and firmware from dozens of Tier 1 and Tier 2 vendors. According to research from TU Berlin presented at ACM ASIA CCS 2025, modern vehicles run code across multiple independent subsystems, each with a completely different security posture. When those components talk to each other, the gaps between them are where vulnerabilities hide — even when each piece looks clean on its own.

The OTA double edge. OTA updates are useful — Tesla patched the VCSEC/TPMS flaw through one. But here’s the thing nobody says: the update delivery system is itself an attack surface. Compromise the pipeline, and you push bad firmware to an entire fleet at once—on a single shot.

AI is making it worse. Per “Three Glitches to Rule One Car” — the ACM ASIA CCS 2025 paper from TU Berlin — the team disclosed fault injection attacks to Tesla’s product security team on the Infotainment system (May 2023), Autopilot HW3 (November 2023), and Autopilot HW4 (August 2024). More AI compute inside the car means more custom silicon, more complex firmware, and more surface area for exactly these kinds of attacks—every model year.

What the Industry Is Actually Doing

To be honest, it’s nothing. The response is real. It’s just slow.

UNECE Regulation No. R155 is the biggest structural shift — and unlike most industry standards, it actually has teeth. It’s the law. Adopted by the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) back in June 2020, R155 requires every OEM selling into its 64 contracting party countries — the EU, UK, Japan, South Korea, Australia, and others — to run a certified Cybersecurity Management System (CSMS). Phase one hit July 2022. Phase two, covering all new production vehicles, took effect in July 2024. Don’t comply? You lose type approval. No type approval, no sales. That’s not a fine — that’s a ban.

I’ll be direct about two things, though. First: R155 doesn’t reach back. Hundreds of millions of cars already on the road aren’t touched by it. A CSMS cert shows process compliance — it doesn’t prove security. Second: the US and China, two of the largest auto markets on earth, don’t operate under UNECE type approval at all. The US runs a self-certification system. China has its own path under GB 44495:2024. R155’s enforcement only bites within its 64 contracting parties. Not globally.

On the hardware side, HSMs are the right answer. Infineon’s AURIX TC3x family, NXP’s S32 automotive processors, and STMicroelectronics’ STSAFE — all now ship with embedded HSM functionality. R155 CSMS compliance essentially requires them: secure boot, cryptographic key management. You can’t show compliance without it. The direction is right. Fleet-wide adoption is a different question — anyone quoting you a precise percentage is working from an analyst model, not a hardware audit.

The money is moving. Precedence Research estimates the automotive cybersecurity market at $5.24 billion in 2025 and at $21.11 billion by 2035. Emergen Research: $4.29 billion now, $29.8 billion by 2035. Different firms, different methods — same direction.

The Human Cost That Hasn’t Been Fully Priced In

The 2015 Jeep Cherokee attack wasn’t an EV. Doesn’t matter. Researchers Charlie Miller and Chris Valasek took remote control of its steering, braking, and transmission over a cellular network — and Chrysler recalled 1.4 million vehicles. That established something that still holds: hardware vulnerabilities in connected vehicles can kill people.

What’s changed since? More connectivity. More software. More autonomy. More attack surface.

A compromised EV isn’t a stolen password. Per the CVE-2025-2082 documentation, the VCSEC exploit in the Tesla Model 3 — if successfully pulled off — enables unauthorized commands to the CAN bus that governs braking and acceleration. CVSS score: 7.5, High severity.

To be precise about this: modern vehicles increasingly use gateway ECUs and domain controllers to wall off safety-critical networks from internet-facing systems. Real exposure depends on the architecture, segmentation, and privilege-escalation paths — it varies by vehicle. But those gateways are software. Running on hardware. Per the ACM ASIA CCS 2025 paper, hardware has documented exploitable fault-injection vulnerabilities. The research keeps proving it.

We’re in the era of responsible disclosure, bug bounties, and OTA patches in EV cybersecurity. Better than nothing. But it assumes attacks stay in the lab.

What You Should Actually Do Right Now

None of these requires a security engineering background—just good habits.

Keep your firmware current. Here’s a real example of why it matters: Synacktiv found the VCSEC flaw (CVE-2025-2082) at Pwn2Own Vancouver 2024 on March 28, 2024, and disclosed it immediately. Tesla patched it in firmware 2024.14 — the Spring 2024 update — which rolled out April/May 2024, within weeks of discovery. The public ZDI advisory didn’t drop until April 30, 2025. Nearly a year’s gap between the patch and public disclosure. That’s responsible disclosure working exactly as designed. But only if your firmware is actually installed. Tesla pushes OTA updates automatically — owners can defer them. Don’t.

Be picky about where you charge. The Hardwear.io/BankInfoSecurity research on exposed SSH, HTTP, and MQTT ports in charging hardware is specific and documented. Stick to major-brand, well-maintained infrastructure when you can. The security posture of a random third-party charger in a parking garage? Genuinely unknown.

Treat infotainment Wi-Fi like any internet-connected device. Because that’s what it is. Same rules apply.

Ask your OEM how they authenticate OTA updates. Most people never do. Software delivered over a network is only as secure as the delivery mechanism. Ask what’s protecting that pipeline.

Where I Actually Land on This

Coming from PCB and electronics manufacturing, here’s what I keep coming back to: hardware decisions made early in a design cycle are the hardest to undo. Not impossible. Just slow, expensive, and incomplete.

The CAN bus with no native authentication wasn’t a case of laziness. It was an 1980s industrial protocol nobody imagined would sit at the core of an $80,000 connected vehicle in 2024. Software patches help. They don’t solve a physical architecture problem.

The Architecture Shift That Could Fix This

The industry is moving toward zonal ECU designs — consolidating 100+ distributed units into 20–30 higher-performance domain controllers. Continental launched its Zone Control Unit (ZCU) platform in April 2024. NXP’s S32 CoreRide is built for exactly this shift. In the early days, high-end platforms were only for now. But the direction is structurally right.

I think this transition is the best shot the industry has at building security from the ground up — from the PCB layout, chip selection, and firmware stack — rather than bolting it on afterward. Automotive electronics already operate under rigorous reliability standards: IPC Class 3 assembly, AEC-Q100 semiconductor qualification, and ISO 26262 functional safety co-design. Cybersecurity needs to be equally foundational. Not a software layer added after the hardware ships.

Your EV’s battery is engineered to withstand specific crash loads. Structural elements are designed to absorb energy in a controlled manner. Thermal systems are designed around defined failure modes.

The hardware talking to your brakes deserves the same rigor.

At the end of the day, your car is unlikely to be targeted tomorrow. The question worth asking isn’t probability. It’s whether the engineers designing these systems are treating security as a first-order requirement or a compliance checkbox. The market is split right now between legacy platforms managing design debt in software and next-generation zonal architectures built to enforce cryptographic hardware trust from the silicon up. Which side of that line your vehicle sits on isn’t a marketing question. It’s an engineering one.

About the author: Imran writes Silicon to Software — a publication covering AI infrastructure, hardware, and the electronics industry from a practitioner’s perspective.

Sources

Synacktiv Pwn2Own 2024 (ECU/CAN bus exploit): Zero Day Initiative (@thezdi), March 20, 2024; BleepingComputer; SecurityWeek; Infosecurity Magazine
CVE-2025-2082 (VCSEC/TPMS exploit): NIST NVD; ZDI advisory ZDI-25-265; VicOne technical analysis (December 2024); Synacktiv Hexacon 2024 presentation; CybersecurityNews (May 1, 2025)
VCSEC timeline: ZDI public advisory; Tesla Oracle (Spring 2024 update confirmation); Tesla service manual (June 2024)
TU Berlin / Black Hat USA 2023: Black Hat 2023 briefing; BleepingComputer (August 8, 2023); TechSpot; The Register; VPNOverview
ACM ASIA CCS 2025 — “Three Glitches to Rule One Car”: ResearchGate (researchgate.net/publication/394889795); ACM DOI: 10.1145/3708821.3710820
EV charging station vulnerabilities: BankInfoSecurity, October 24, 2024 (van Beijnum and Tol, Hardwear.io)
CVE-2024-37310 (EVerest charging stack): NIST NVD; PlaxidityX advisory; GitHub EVerest/everest-core
PlaxidityX charger impersonation research: PlaxidityX blog (plaxidityx.com); ISO 15118 cybersecurity guide
ECU count (70–150+ per vehicle): Bosch Corporation; Aptiv ECU technical documentation
CAN bus architecture: Bosch Corporation; Dewesoft technical documentation; SAE technical paper 2024-01-3979
UNECE R155 regulation: UN Regulation No. 155 (UNECE, June 2020); VicOne R155 enforcement analysis; Uraeus R155 regulatory guide
US/China regulatory frameworks: CYEQT UN R155 worldwide analysis (February 2026)
HSM integration: Infineon AURIX TC3x; NXP S32 automotive processors; STMicroelectronics STSAFE
ISO/SAE 21434: SAE International / ISO joint standard
IPC Class 3 / AEC-Q100 / ISO 26262: IPC Association; AEC (Automotive Electronics Council); ISO
Automotive cybersecurity market: Precedence Research (May 2026); Emergen Research (May 2026)
Continental ZCU / NXP S32 CoreRide: Continental press release April 2024; NXP S32 CoreRide product documentation
Jeep Cherokee 2015 hack: Miller & Valasek; Chrysler recall documentation