Tesla Gets Hacked Every Year at Pwn2Own. 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.
About the Author
Imran Valiani | Sales Director, PCB Electronics Manufacturing — 20+ years working with major Bay Area and global tech clients. Founder of Silicon to Software, where I write about the hardware layer — PCB fab, AI gear, autonomous systems, and cyber — the stuff most tech writers have never touched. Literally. Follow: X @SiToSoftware | LinkedIn
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.
EV cybersecurity has a hardware problem — and it goes deeper than most people realize.
Table of Contents
It Took Under 30 Seconds
March 2024. Vancouver. Synacktiv — a French cybersecurity firm — walks up to a brand-new, fully patched Tesla Model 3 at Pwn2Own. One integer overflow flaw in the car’s Electronic Control Unit (ECU). That’s it. Per the Zero Day Initiative’s live event log, they gained Vehicle (VEH) CAN BUS Control in what BleepingComputer described as “a matter of moments.”
Two hundred thousand dollars. And the car. Their second one (they took a Model 3 home from Pwn2Own Vancouver 2023 too).
Quick context if you’re new to this: Pwn2Own is an annual hacking contest run by Trend Micro’s Zero Day Initiative (ZDI). Researchers hit real, fully patched devices. They keep whatever they compromise. Every flaw gets reported to the vendor before anything goes public. Tesla shows up voluntarily. Unmodified cars. No handicap.
I think that’s the detail most people skip past. It’s not that Tesla got hacked once. Synacktiv has walked into the same competition multiple years in a row, found a new way in every single time, and walked out with control of the car. Different attack surfaces. Same outcome.
Here’s the thing — this isn’t really a Tesla story.
Tesla is among the most software-connected EV platforms globally. That’s exactly why it gets tested the most. But what do these researchers keep finding? Whatever’s inside Tesla’s hardware exists, in some form, in every modern EV on the road. Embedded cellular connectivity is now standard across most new EV platforms — built in at the factory, not bolted on later. That’s been true since the early 2020s. And the market hasn’t reversed.
We don’t talk about this. We argue about range. Charging speeds. Battery degradation. But the hardware sitting between you and a potential attacker? Barely gets a mention.
That changes here.
Your Car Has 150 Computers. Most Weren’t Designed Around Security.
I’m going to skip ahead and go straight to the thing that genuinely broke my brain: someone exploited a Tesla through its tire pressure sensors.
Same competition — Pwn2Own 2024. Same team. Per VicOne’s technical analysis and Synacktiv’s own Hexacon 2024 presentation, researchers David Berard and Thomas Imbert found that malformed certificate responses in the TPMS pairing process could trigger an integer overflow in the Vehicle Controller Security (VCSEC) module. The VCSEC isn’t some peripheral chip — it controls door locks, the immobilizer, vehicle startup, and interfaces directly with the CAN bus. When exploited, the out-of-bounds write into the VCSEC’s heap memory gave them arbitrary code execution. Zero-click. No driver interaction at all.
Here’s what made it land so cleanly: per VicOne’s analysis, the VCSEC uses a memory configuration that’s simultaneously readable, writable, and executable (RWX). That’s a serious misconfiguration. Proper secure memory design keeps writable and executable regions separate — when both are live at once, you can inject code straight into memory and run it. No extra privilege escalation needed. Just in.
The attack runs over adjacent wireless interfaces in the VCSEC’s communication stack — Bluetooth Low Energy (BLE) and Ultra-Wideband (UWB), per Synacktiv’s Hexacon 2024 deck. An attacker needs to be within wireless range. Not remote. Not over the internet.
Maybe I’m wrong to find that reassuring. Parking garages exist. Valet lines exist. Charging queues exist. Proximity isn’t hard to arrange.
Your tires. Attack vector. Sit with that.
Okay — so why does any of this work? Here’s the context.
A modern EV isn’t a car with a computer in it. It’s a computer that happens to have wheels. Most carry 70 to 150+ Electronic Control Units — each one a dedicated embedded chip running one job: brakes, steering, airbags, thermal management, power conversion. That range is well documented in Bosch and Aptiv engineering literature.
All of those ECUs talk to each other through the Controller Area Network — the CAN bus. Bosch designed it in the 1980s for factory machines. Per Dewesoft’s technical documentation, it was built “to allow the ECUs found in today’s cars to communicate with each other in a reliable, priority-driven fashion.”
Smart for 1986. The problem is it was never designed with security in mind. Not even slightly. Peer-reviewed automotive security research has consistently flagged the absence of native message authentication and encryption in classic CAN bus protocols as a fundamental, widespread weakness. Messages travel as plain text. An ECU can’t verify who sent what. Modern architectures try to layer controls on top — AUTOSAR Secure Onboard Communication (SecOC), gateway filtering, message authentication codes — but these overlays aren’t universally deployed across the fleet. Most OEM workflows now align with ISO/SAE 21434 as the engineering standard for R155 compliance, but that’s a recent shift.
I’ve found that this is the hardest thing to explain to people outside the PCB manufacturing world: legacy design debt doesn’t go away when you patch software. You can layer code over a physical architecture problem. You can’t re-route the bus.
The Attack Surfaces Nobody Is Talking About
How does an attacker get in? They don’t need your windows.
I’ve noticed that people assume physical access is the starting point for serious automotive attacks. It’s not. Sometimes the easiest door is the one you use every week.
The charging port. In October 2024, researchers at Hardwear.io presented findings titled “Hacking EV charging stations via the charging cable.” Per BankInfoSecurity’s coverage, they tested hardware from 13 manufacturers — 18 DC stations and one AC unit. Half were exploitable. Eight left SSH ports wide open. Others exposed HTTP and MQTT protocols. Just sitting there.
PlaxidityX (formerly Argus Cyber Security) documented two separate attack paths through the charging interface. First: CVE-2024-37310, an integer overflow in the V2G Transport Protocol implementation of the EVerest open-source charging stack. A remote attacker can overflow the charging station’s heap — gaining code execution on the station itself, compromising private keys, bypassing payment systems, and impersonating the station to backend infrastructure. Second — and separately — PlaxidityX demonstrated full charger impersonation at the charge port: mimic the signals, connect, push bad data into the vehicle’s internal network. No driver action required. These are two sides of the same problem: the charging infrastructure is vulnerable, and so is the vehicle’s trust in it.
Not great.
The infotainment system. In August 2023, researchers from Technische Universität Berlin — Christian Werling, Niclas Kühnapfel, Hans Niklas Jacob, and independent researcher Oleg Drokin — presented at Black Hat USA 2023. Per their briefing and BleepingComputer’s coverage, they used a voltage fault injection attack against Tesla’s AMD Secure Processor (ASP), the root of trust for the MCU-Z infotainment system. One hard constraint: this requires physical access. Per The Register’s coverage, the researchers soldered wires directly to the infotainment ECU to manipulate power delivery at exactly the right moment. Past the ASP, they had root access to the Linux-based infotainment OS and could run arbitrary code. They unlocked Acceleration Boost and Full Self-Driving Beta without paying (a nice trick). But that’s not what made me stop.
The path they used could expose hardware-bound RSA keys Tesla uses to authenticate each vehicle, decrypt NVMe storage, and access private user data. The researchers described it as “unpatchable” in software because the flaw is in the hardware itself.
I know what you’re thinking — controlled lab conditions. Fair point. Controlled research becomes real-world playbook faster than most people expect, though.
Why EV Cybersecurity Faces a Broader Attack Surface Than Most Connected Devices
I’ve found that people assume newer technology means better security. It doesn’t. Here’s why EV cybersecurity has a structurally harder problem than most connected device categories.
Scale of connectivity. Your EV talks to a lot of things simultaneously — charging networks, OEM cloud servers, OTA update pipelines, V2X systems, your phone. Every connection is a door. Analysts at Upstream Security and VicOne consistently flag the same two culprits: telematics control units (TCUs) and infotainment systems. Most exposed. Historically least protected.
Supply chain chaos. One EV pulls ECUs, chips, sensors, and firmware from dozens of Tier 1 and Tier 2 vendors. Per TU Berlin’s research presented at ACM ASIA CCS 2025, modern vehicles run code across multiple independent subsystems with completely different security postures. When those components communicate, the gaps between them are where vulnerabilities hide — even when each individual piece looks clean in isolation.
The OTA double edge. OTA updates are useful — Tesla patched the VCSEC/TPMS flaw through one. But the update delivery system is itself an attack surface. Compromise the pipeline, push bad firmware to an entire fleet at once. One shot. Every car.
AI 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 targeting the Infotainment system (May 2023), Autopilot HW3 (November 2023), and Autopilot HW4 (August 2024). More AI compute in the vehicle means more custom silicon, more complex firmware, more attack surface. Every model year.
What the Industry Is Actually Doing
To be honest — it’s not nothing. The response is real. It’s just slow.
UNECE Regulation No. R155 is the biggest structural move — and unlike most industry standards, this one actually has teeth. It’s law. Adopted by the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) 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: July 2022. Phase two, all new production vehicles: July 2024. Don’t comply? You lose type approval. No type approval, no sales. That’s not a fine. That’s a ban.
Two things worth being direct about. 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 don’t operate under UNECE type-approval at all. The US uses self-certification. China has its own path under GB 44495:2024. R155’s enforcement 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, STMicroelectronics’ STSAFE all ship with embedded HSM functionality now. 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 drawing from an analyst model, not a hardware audit.
The money is moving. Precedence Research puts automotive cybersecurity at $5.24 billion in 2025, heading to $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 connection — and Chrysler recalled 1.4 million vehicles. It proved something that still holds: hardware vulnerabilities in connected vehicles can kill people.
What’s different now? More connectivity. More software. More autonomy. More surface area.
A compromised EV isn’t a stolen password. Per CVE-2025-2082 documentation, the VCSEC exploit in Tesla Model 3 — if pulled off — enables unauthorized commands to the CAN bus governing braking and acceleration. CVSS score: 7.5, High severity.
To be precise: modern vehicles increasingly use gateway ECUs and domain controllers to wall off safety-critical networks from internet-facing systems. Real exposure depends on 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 responsible disclosure, bug bounty, OTA patch era of EV cybersecurity. Better than nothing. But it assumes attacks stay in the lab.
What You Should Actually Do Right Now
None of this requires a security background. Just good habits.
Keep your firmware current. Real example: 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 — rolling out April/May 2024, weeks after discovery. The public ZDI advisory didn’t drop until April 30, 2025. Nearly a year between patch and public disclosure. That’s the responsible disclosure system doing exactly what it’s supposed to. But only if your firmware is actually installed. Tesla’s OTA system pushes automatically — owners can defer. 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. Use 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 owners never do. Software over a network is only as secure as the delivery mechanism. Ask what’s protecting it.
Where I Actually Land on This
Coming from PCB and electronics manufacturing, here’s what I keep returning to: hardware decisions made early in a design cycle are the hardest to undo. Not impossible. Just slow, expensive, and rarely complete.
The CAN bus with no native authentication wasn’t laziness. It was a 1980s factory protocol nobody imagined would sit at the core of an $80,000 connected vehicle in 2024. Software helps. It doesn’t fix a physical architecture problem.
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 specifically for this shift. Early days. High-end platforms only, for now. But the direction is right.
I think this transition is the best shot the industry has at building EV cybersecurity in from the ground up — PCB layout, chip selection, firmware stack — rather than bolting it on afterward. Automotive electronics already operate under serious reliability standards: IPC Class 3 assembly, AEC-Q100 semiconductor qualification, 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 survive specific crash loads. Structural elements calculated to absorb energy in defined ways. Thermal systems built around documented failure modes.
The hardware talking to your brakes deserves the same treatment.
At the end of the day — your car is unlikely to be targeted tomorrow. The question isn’t probability. It’s whether the engineers designing these systems treat security as a first-order requirement or a compliance checkbox. The market is split right now: legacy platforms managing design debt in software on one side, next-generation zonal architectures built to enforce cryptographic hardware trust from the silicon up on the other. 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 — covering AI infrastructure, Hardware, and the electronics industry from a practitioner’s perspective. Follow on X @SiToSoftware and LinkedIn.
This post was written with AI assistance. See my full AI disclosure.
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
