The contest produced headline numbers. The deeper lesson is that familiar implementation failures still create practical attack paths across infotainment, open-source vehicle platforms, and EV charging infrastructure.
| 76
unique zero-days |
$1.047M
awarded over three days |
Multiple
successful exploit chains |
Pwn2Own Automotive 2026 ended with 76 unique zero-day vulnerabilities and $1,047,000 in awards. Those figures are impressive, but they are not the most important result for OEMs and suppliers. The more useful signal is how researchers reached meaningful impact: through authentication failures, command injection, memory-safety defects, dangerous exposed functions, insecure update paths, and multi-bug chains.
These are not exotic, theoretical weaknesses. They are recurring engineering failures that disciplined security testing is designed to uncover before a product reaches an OEM integration lab — or a customer environment.
Automotive risk extends well beyond the vehicle
The 2026 targets covered in-vehicle infotainment systems, Automotive Grade Linux, Tesla infotainment via USB, and several EV chargers. That range reflects the real connected-mobility ecosystem. A modern automotive product is rarely a single embedded device. It is part of a chain that may include:
- Vehicle ECUs, gateways, infotainment, and telematics
- Wireless and physical interfaces
- Charging equipment and charging protocols
- Backend services, cloud infrastructure, and APIs
- Mobile applications, fleet portals, and service tooling
A security assessment limited to one component can therefore produce a false sense of confidence. The relevant question is not only whether an attacker can compromise a device. It is whether that foothold can cross a trust boundary, reach another system, manipulate a signal, expose credentials, or create a persistent path into the wider platform.
The unit of risk is no longer the ECU. It is the connected system — and the trust relationships between its parts.
Familiar vulnerability classes still create serious impact
The published results repeatedly reference command injection, buffer overflows, out-of-bounds reads and writes, hardcoded credentials, authentication bypasses, incorrect permissions, race conditions, and insecure firmware-update behavior. On Day One alone, researchers used a hardcoded credential and an update-related weakness to achieve code execution on an EV charger. Other teams chained authentication bypass with remote code execution or combined several defects to manipulate charging signals.
This matters because automotive security conversations often focus on advanced cryptography, sophisticated vehicle networks, or novel attacker techniques. Those controls matter — but products still fail through basics: an exposed maintenance function, unsafe parsing, weak privilege boundaries, or a secret embedded in firmware.
Practical implication: a credible automotive penetration test must examine ordinary implementation weaknesses as aggressively as vehicle-specific protocols. Secure design cannot compensate for an unsafe function that is reachable in the final build.
Exploit chains are the real story
Several successful entries combined two, three, or even five vulnerabilities. This is closer to how meaningful compromise happens in practice. A single issue may appear moderate when assessed alone. Combined with an information leak, weak authentication, incorrect permission, or update flaw, it can become a path to privileged code execution or system manipulation.
This is where checklist testing underperforms. Testing each interface independently may identify isolated defects while missing the sequence that connects them. Strong automotive pentesting follows attacker logic:
- Gain initial access through a physical, wireless, local, or remote interface.
- Escape the exposed service or low-privilege context.
- Obtain credentials, keys, sensitive files, or additional reachability.
- Move across component, network, or cloud trust boundaries.
- Demonstrate concrete impact without exceeding agreed safety limits.
EV charging is part of the automotive threat model
EV chargers were not side attractions at the contest. Researchers achieved code execution, privilege escalation, authentication bypass, and charging-signal manipulation across multiple products. The results make a simple point: charging infrastructure combines embedded software, network connectivity, protocols, cloud services, mobile control, payment or identity data, and physical-world behavior.
For suppliers, the ownership boundary can be misleading. A charger, control module, protocol library, or cloud API may sit outside the vehicle program, yet still affect vehicle availability, customer trust, and OEM risk. Security scope should follow technical dependencies and potential impact — not organizational charts.
Compliance evidence and attack evidence are different
ISO/SAE 21434 provides a framework for cybersecurity engineering across the road-vehicle lifecycle. A TARA, cybersecurity plan, requirements set, review record, and traceability package can show that a process exists and that risks were considered. They do not prove that the production implementation resists a determined attacker.
Pwn2Own shows why technical validation is necessary. Design assumptions can be correct while the code contains a memory defect. An update architecture can require authenticity while a deployed component accepts an unsafe path. A service can be documented as restricted while permissions or exposed methods make it reachable.
Pentesting closes that evidence gap. It tests the integrated product, identifies exploitable combinations, demonstrates business-relevant impact, and verifies whether remediation actually removes the attack path.
What OEMs and suppliers should do now
The practical response is not to copy the contest. It is to bring the same adversarial mindset into product development early enough to change the outcome.
Test the attack chain, not only the component. Include device, vehicle interfaces, update flow, cloud/API exposure, mobile control, and service tooling where they form one system.
Prioritize reachable implementation risk. Threat models should guide the test, but the engagement must probe the actual build for common weakness classes and unsafe defaults.
Include chaining in the test methodology. Do not close findings as isolated tickets before evaluating whether they combine into higher-impact paths.
Retest remediation. A patch is not evidence. Verify that the exploit path is removed and that the fix did not move the weakness elsewhere.
Give OEM customers usable evidence. Provide clear scope, reproducible findings, demonstrated impact, remediation status, and residual-risk decisions — not a generic certificate.
The bottom line
Pwn2Own Automotive 2026 does not show that every automotive product is easily compromised. It shows that serious, exploitable weaknesses remain discoverable in current products — and that attackers can combine familiar defects to reach meaningful impact.
For automotive suppliers, that is a business issue as much as a technical one. The strongest time to find these paths is before an OEM does, before validation delays a program, and before a deployed product turns a preventable defect into an incident.
| A useful next question
Could an independent team move from your product’s most exposed interface to an outcome your customer would consider material? |
Sources
- Zero Day Initiative — Pwn2Own Automotive 2026: Day Three Results and Master of Pwn
- Zero Day Initiative — Pwn2Own Automotive 2026: Day One Results
- Zero Day Initiative — Pwn2Own Automotive 2026: Day Two Results
- ISO — ISO/SAE 21434:2021, Road vehicles — Cybersecurity engineering
