Shin Li, Staff Threat Researcher, Automotive
Pwn2Own Automotive, the world’s largest automotive zero-day vulnerability contest, spotlighted zero-day vulnerabilities for electric vehicle supply equipment (EVSE). In its first run in 2024, researchers uncovered 29 vulnerabilities across various electric vehicle (EV) charging products, including the Phoenix Contact CHARX SEC-3100 EV charging controller, half of which allowed remote code execution (RCE). The other attacks ranged from unauthenticated firmware updates and configuration injections to arbitrary file uploads and privilege escalations.
These findings underscore the mounting cybersecurity risks in EV charging infrastructure and raise urgent questions about whether today’s standards can sufficiently protect the EV ecosystem. To help answer that, we conducted a clause-level mapping effort to understand how today’s major EVSE cybersecurity standards address — or fail to address — the types of vulnerabilities revealed in the contest.
Mapping vulnerabilities against EVSE standards
For this study, we focus on the vulnerabilities discovered in the Phoenix Contact EV charging controller, as detailed by security researchers from NCC Group in their presentation at 44CON.
Table 1 maps the key vulnerabilities discovered by NCCGroup against these EVSE cybersecurity standards: ISO 15118-20:2022 (V2G protocol), NIST IR 8473 (EV/XFC cybersecurity profile), IEC 62443-3-3/4-2 (industrial control security), and UN ECE R155 (vehicle cybersecurity regulation). Coverage is assessed based on the standards’ clauses, notes, and annexes. Each row includes our assessment and explanatory notes that clarify whether a requirement truly mitigates the issue, touches it only indirectly, or falls outside the standard’s intended scope.
Note that ISO 21434 (automotive cybersecurity engineering) is not listed in Table 1. While the standard notes that “systems external to the vehicle (e.g., backend servers) can be considered for cybersecurity purposes,” it also states that such systems are out of scope. Chapter 8 on continual cybersecurity activities may inform good practice, but it is far from being mandatory.
UN R155, on the other hand, requires manufacturers to consider all three parts of Annex 5 in their risk assessment. While Part B addresses in-vehicle mitigations, Part C extends to systems outside the vehicle, such as IT backends. Notably, Table B4, A16.1 explicitly lists the “charging pile” among remotely operated functions that may be manipulated, mapping it to mitigation M20 (“security controls shall be applied to systems that have remote access”). For this reason, we evaluate EVSE-related vulnerabilities using Annex 5 as the threat-mitigation framework to ensure that the vehicle manufacturer’s obligations regarding interfaces with charging infrastructure are adequately addressed.
| Vulnerability | ISO 15118-20 | NIST IR 8473 | IEC 62443 | UN R155 | Notes |
|---|---|---|---|---|---|
| CVE-2024-6788: unauthenticated LAN firmware-update / endpoint resets “user-app” password to default, enabling SSH RCE | Not in scope – 7.3 limits the scope to EVCC↔SECC TLS-protected V2G messages. Firmware, OTA, and non-V2G are out of scope. | PR.IP-3 (Configuration Change Control) | 62443-3-3 SR 3.4 (software and information integrity) | A12.2 A6.1/6.2 M16 | Firmware update should not erase existing configurations. |
| CVE-2024-25995 (ZDI-24-856) unauthenticated 5001/TCP configuration API injection → RCE via PPP script execution | Beyond the scope; port not listed in supported ports (Clause 7.8.2 “V2GTP” uses high ports); no requirements for management APIs | PR.AC-1/PR.AC-4 (access control/ least privilege); PR.PT-3 (least functionality); PR.IP-1 (baseline configuration of IT/ICS) | 62443-4-2 CR 2.1 (authorization enforcement). | A16.1 A5.1 A29.1 M20 M22 | Administrative API entry point should be authenticated. User input should be sanitized. |
| CVE-2024-25994 (ZDI-24-867) 9999/TCP arbitrary file upload with execute permission → RCE | Not in scope | PR.PT-2 (removable media/ file transfer control); PR.IP-2 (secure SDLC for input validation) | 62443-3-3 SR 3.2 (malicious code prevention). | A16.1 A5.1/ 5.5 A29.1 M7 M20 M22 | Uploaded files should be parsed and validated. File permissions should be restrictive. |
| CVE-2024-25999 (ZDI-24-865) local privilege escalation via sudo tar --checkpoint-action injection in management script | Administrative system not in scope | PR.AC-4 (least privilege); PR.PT-3 (least functionality); PR.IP-2 (secure SDLC/input validation); PR.MA-1 (approved maintenance tools) | 62443-3-3 SR 3.5 (Input validation). | A9.1 A28.1 / 28.2 M9 M23 M7 | Unsafe scripts should not run with root privileges. Command line injection should be mitigated. |
| Multiple clear-text HTTP services (e.g., 4444/5000/5001/ 9999) with default credentials, enabling MITM/injection (no CVE) | TLS 1.3 mandatory only for V2GTP streams (Clause 7.7.3) | PR.PT-4 (communications /network protection); PR.DS-2 (data-in-transit protection) | 62443-3-3 SR 3.8 (Session integrity). | A6.2 / A6.3 / A6.1 A7.1 / A7.2 A29.1 A20.1–A20.5 / A25.2 M7 M8 | Latest TLS should be used to mitigate man-in-the-middle (MITM) attack. |
| Unexploited but identified: Cython -compiled memory safety defects (e.g., buffer overflows in reverse-engineered code) | Not in scope | PR.IP-2 (secure SDLC with static/ dynamic analysis); PR.DS-6 (integrity checking) | 62443-4-1 (secure development) | A28.1 A27.1 M23 | Memory issues could be mitigated by software-development lifecycle (SDLC) |
Table 1. Mapping the vulnerabilities discovered in the Phoenix Contact EV charging controller against major EVSE cybersecurity standards
As shown in Table 1, the specific vulnerabilities could be addressed by NIST IR 8473 control families (e.g., PR.IP and PR.MA) and by IEC 62443 system requirements. However, gaps arise from voluntary implementation and scope limitations across standards. ISO 15118-20, for instance, secures only V2G communication protocols (Clause 7.3), without explicit regulations on firmware and management tasks. UN R155 Cybersecurity Management System (CSMS) framework (Paragraph 7.2) mandates remediation but focuses primarily on vehicles instead of EVSE.
None of the vulnerabilities directly violated ISO 15118-20. Yet, the results of Pwn2Own Automotive 2024 clearly showed that these vulnerabilities were exploited within minutes, despite the presence of existing cybersecurity countermeasures.
To strengthen protection of EVSE infrastructure, ISO 15118-20 should be complemented, not replaced, by OT–focused standards such as IEC 62443 and EV/EVSE-specific guidance such as NIST IR 8473.
Layered but uneven defense
These standards collectively create a layered defense for EV charging infrastructure, with protocol-specific protection built on top of broader systems. However, the integration among these layers is uneven. ISO 15118-20, for example, focuses narrowly on securing the V2G communication channel and leaves firmware vulnerabilities outside its regulatory scope.
NIST IR 8473 stands out as a key integrator, synthesizing diverse references into 108 EV/XFC-specific subcategories. An analysis across these 108 subcategories and 422 references shows that NIST SP 800-53r5 is the most referred standard. It is followed by IEC 62443 series (14% of references from 62443-2-1:D4E1 and 9% from 62443-3-3:2013), NERC CIP standards, and metering/measurement standards such as NIST Handbook 44 and OIML. Additional references include ISO/SAE 21434, NIST incident handling, among others (e.g., 3% of NIST SP 800-160v1). The percentages are shown in Table 2.
| Standard/Source | Proportion of References (%) |
|---|---|
| NIST SP 800-53r5 | 26% |
| IEC 62443 Series | 23% |
| NERC CIP | 17% |
| Metering Standards (e.g., NIST Handbook 44, OIML) | 6% |
| ISO/SAE 21434 | 4% |
| NIST Incident Handling (e.g., SP 800-61r2) | 5% |
| Others (e.g., NIST SP 800-160v1) | 19% |
Table 2.Reference distribution across standards cited in NIST IR 8473
The distribution reflects the nature of NIST IR 8473, which derives from a catalog of security and privacy controls (NIST 800-53). It emphasizes the convergence of IT and OT requirements in EV/XFC systems (IEC 62443) and grid-related risks (NERC CIP). ISO/SAE 21434 is referenced in 18 subcategories for automotive engineering, while NERC CIP is referenced in 71 for utility risks.
Gaps in EVSE standards
Each of the standards covers and mitigates part of the exploited vulnerabilities, but they are most effective when implemented together. ISO 15118‑20:2022, for example, limits security to the EVCC–SECC V2G link (OSI L3–L7). It mandates mutually authenticated TLS 1.3 and EXI/XML signatures, but assumes secure transport to Secondary Actors without defining the SECC–SA mechanisms. As a result, platform-level controls for firmware, maintenance ports, and other charger surfaces must come from complementary specifications and operator governance.
NIST IR 8473, a risk-based profile across 108 subcategories, offers checklists for operators and suppliers, emphasizing signed updates, maintenance approvals, and anomaly detection (PR.MA, DE.CM). In Pwn2Own Automotive 2024, several EV exploits map to Identity Management, Access Control, and Information Protection categories. Its “applicability” notes help bridge general IT/OT standards to charging systems, but the profile remains voluntary and its references advisory.
IEC 62443 (3-3 and 4-2) focuses on embedded system hardening, including software/information integrity (SR 3.4), malicious-code protection (SR 3.2), and secure configuration (SR 7.6). Component-level requirements, such as authentication and least functionality, are added in IEC 62443-4-2. A few of the EV vulnerabilities in Pwn2Own Automotive 2024, such as unauthenticated configuration APIs, fall directly within its scope. However, the framework assumes a zoned architecture, which is not implemented in the Phoenix Contact EV charging controller.
ISO 21434 establishes a CSMS and threat analysis and risk assessment (TARA) across the automotive SDLC (§10; §8.6), mandating remediation for issues such as CVE-2024-25999 and identifying injection risks. Although complementary to IEC 62443, it is vehicle-oriented but might be extended to chargers through supply chain requirements (§7).
UN ECE R155 mandates a CSMS across development, production, and post‑production phases (7.2.2.1), with manufacturers required to apply all relevant Annex 5 mitigations (Parts B and C). For update‑process threats (A12.x), this includes M16 (secure update procedures) and M11 (secure storage of cryptographic keys). Annex 5 also addresses external connectivity (A16.1 explicitly names the “charging pile” mapped to M20) and data risks, including privacy data access (B5 19.2), vehicle data loss/breach (B7 31.1), and backend “data breach” scenarios in Part A 4.3.1 (item 3). While R155 is vehicle‑centric, the regulation obliges car manufacturers to consider areas outside the vehicle, including EVSE.
In the case of the Phoenix Contact EV charging controller, these gaps became evident in how the researchers successfully chained multiple vulnerabilities to compromise the device. They combined unauthenticated APIs, misconfigured file permissions, and unsanitized input from DHCP and PPPD, showing that:
- Voluntary scheme fails: Mandatory TLS in ISO 15118-20:2022 (Clause 7.7.3) was not applied to maintenance ports. NIST IR 8473 PR.DS-2 (encryption) and UN R155 M20 (remote access controls, Table B4) are supported by the operating system but not implemented. The absence of TLS enabled the MITM attack on HTTP services.
- Compliance testing gaps: ISO 15118-20 conformity testing covers V2G protocol but overlooks OT elements such as the “sudo” vulnerability that violates IEC 62443-3-3 SR 3.5. ISO 21434 TARA could flag such risks, but it is not required for EV chargers. UN R155 has a vehicle-centric approval process (Paragraph 5.1) and defines no separate type‑approval scheme for EVSE.
- Exploit chains: Static conformance assessments (such as NIST IR 8473 self-assessments) overlook dynamic exploit chains, which can only be uncovered through red teaming or penetration testing.
Unexploited risks, such as latent memory issues in compiled code, further illustrate SDLC deficiencies (ISO 21434 §5,6,10; NIST IR 8473 PR.IP-2) that can lead to more RCE vulnerabilities.
A compliance perspective
The uneven cybersecurity protections revealed in the standards analysis may activate mandatory cybersecurity requirements under multiple regional and international regulations. Failure to comply withthese EVSE standards may independently trigger obligations under EU NIS2, AFIR, U.S. NEVI, and UN R155:
- NIS2 (Directive (EU) 2022/2555) requires essential and important entities to implement appropriate and proportionate cybersecurity risk‑management measures, including vulnerability handling and disclosure (Article 21:1).
- AFIR (Regulation (EU) 2023/1804) sets interoperability and data/API obligations for alternative‑fuels infrastructure. Recital (75) requires that communications between the EV and charge point, backend, roaming, and the grid must maintain “the highest level of cybersecurity protection,” while Articles 20–21 and Annex II establish data access and common technical specifications.
- In the U.S., NEVI standards at 23 CFR §680.106(h) mandate both physical and cybersecurity strategies. These include identity and access management, cryptographic agility, monitoring and detection, incident response, configuration and vulnerability management, software update governance, and independent third-party cybersecurity testing and certification.
- UN R155 imposes additional obligations on vehicle OEMs. Paragraph 8 requires notifying the authorities of any modification that affects cybersecurity. Paragraph 10 allows withdrawal of type approval for non‑conformity. Paragraph 6.11 links CSMS certificate expiry or withdrawal to such modifications, and Paragraph 7.2.2 extends the manufacturer’s cybersecurity responsibilities across development, production, and post-production, including testing and continuous monitoring.
Considering these legal obligations and the fact that existing international standards already cover most aspects of EVSE cybersecurity, VicOne strongly advocates implementing NIST IR 8473 as a unifying profile to strengthen protection of the EV charging infrastructure.
Conclusion
The EV vulnerabilities discovered in Pwn2Own Automotive offer a unique view into how EVSE cybersecurity standards are expected to provide layered protection for charging infrastructure, where these standards fall short, and which unifying framework can help strengthen overall security.
Although we examined only a single EV charger, the findings suggest that today’s EVSE standards may still contain gaps that could be exposed by zero-day vulnerabilities in other charging devices. And with Pwn2Own Automotive 2026 on the horizon, the industry has an opportunity to build on these insights, close systemic gaps, and elevate the security posture for the next generation of EV charging infrastructure.
