EV Charging Stations: Plain Shell, Complex Core
Calling an EV charger a 'simple box of electricity' is easy, but these are grid-connected, remotely managed network nodes. A map of the hardware, network, and legal attack surface through OCPP, ISO 15118, Juice Jacking, CVE-2018-17182, and Brokenwire (CVE-2022-0878).
EV Charging Stations: Plain Shell, Complex Core
Most of us glance at a charging station and think "just a simple box of electricity." In reality these devices are network nodes wired into the power grid that process payments and talk to the vehicle. This post collects notes I have kept on the topic: the hardware architecture, the network protocols, real CVEs, and the defensive side.
Note: The CVEs and standards below are verified against primary sources (NVD/CVE records, vendor documentation). This post is for defense and awareness.
Hardware architecture: what can go wrong?
A DC fast charger rests on three parts: power electronics, a controller (CPU board), and communication modules (Ethernet/4G/RF). Safe charging relies on RCD (residual current device) and overcurrent protection per IEC 61851 and IEC 62196.
DC stations running at 600 A and above get hot, so liquid cooling enters the picture. That thermal management is usually monitored and controlled remotely over IoT or SCADA. Now consider an attacker reaching that layer: stopping fans, manipulating valves, ignoring temperature thresholds. The result is hardware degradation, service loss, and at worst a fire. A cyber attack is therefore not always about data; it can cause physical damage. This is what separates OT (operational technology) security from IT security.
Physical access: a door left open
Service ports on field chargers, and occasionally public USB outlets, are an invitation for malicious software. Juice Jacking is malicious hardware placed in a public USB charging point infecting or exfiltrating from the connected device. It is classic but effective, and the fix is simple: charge-only cables and data-blocking settings.
The cabinet lock, sealing, and overall integrity are also a defensive line: physical access to an internal service port directly targets the controls a remote attacker cannot easily bypass (secure boot, signed firmware).
Embedded systems and kernel vulnerabilities
EVSE controllers typically run customized Linux distributions, so kernel vulnerabilities put device control at risk. One concrete example:
- CVE-2018-17182 — a sequence-number overflow in the Linux kernel
vmacache_flush_allfunction (mm/vmacache.c), a use-after-free. It existed from kernel 3.16 and was fixed in 3.16.58, 4.4.157, 4.9.128, 4.14.71, and 4.18.9. Reported by Jann Horn (Project Zero), it lets a locally unprivileged user escalate privileges on configurations where the exploit succeeds. Privilege escalation means full control of the affected device.
The key point: the upstream kernel patches such bugs quickly, but embedded vendors often ship the fix weeks (sometimes months) later. Field devices stay exposed during that window. On the hardware side, Secure Boot and a Root of Trust (RoT) ensure only cryptographically signed firmware runs; that is the first line against physical tampering.
Network protocols: the fun starts here
Communication between the EVSE and the central management system (CMS) — and the vehicle — is a target for both operational continuity and data privacy.
DoS/DDoS is a serious threat: an attacker controlling thousands of chargers can switch them on and off in unison, inducing load swings on the local grid. As V2G (Vehicle-to-Grid) spreads, bidirectional energy flow makes this more critical; coordinated manipulation can cause grid spikes. Protocol-level vectors such as SYN Flood also apply. Catching them early means monitoring not just network traffic but CPU usage, memory consumption, and system response times.
OCPP: protocol security is critical
Open Charge Point Protocol (OCPP) is the main channel between the EVSE and the CMS: management, billing, and operational traffic all flow through it. Because it carries sensitive user data and critical control commands, attackers focus here.
Man-in-the-Middle (MitM) can listen to, relay, or modify OCPP traffic. The result: stolen payment data and unauthorized charge commands. Mitigation requires firewalls, VPN tunnels, and end-to-end TLS. The ISO 15118 standard provides secure authentication such as Plug and Charge (PnC) and strong MitM protection.
Version differences matter: OCPP 2.0.1 ships advanced security profiles and native ISO 15118 support (mutual PKI certificate management, strong TLS). The widely deployed OCPP 1.6J implements PnC by wrapping it over ISO 15118 via the protocol's "Data Transfer" mechanism, which widens the surface.
Wireless/PHY layer: Brokenwire (CVE-2022-0878)
One frequent misconception is worth correcting. CVE-2022-0878 ("Brokenwire") is not an OCPP or PnC authentication flaw. It is a DoS that disrupts the control link between vehicle and charger over the HomePlug Green PHY (HPGP) power-line communication (PLC) used by CCS/DC fast charging, by means of electromagnetic interference (EMI):
- Impact: charging sessions abort; a single vehicle or an entire fleet can be disrupted at once.
- Access: wirelessly, at range; successful from ~47 m with a 1 W power budget, off-the-shelf radio hardware, and minimal technical knowledge.
- Root cause: the behavior is a mandatory part of the HomePlug Green PHY, DIN 70121, and ISO 15118 standards; all known implementations exhibit it.
- Record: CWE-306 (missing authentication for critical function), CVSS 6.5 (Medium). Scope is not only cars; electric ships, aircraft, and heavy-duty vehicles are affected.
So "protocol security" and "physical/RF-layer security" must be handled separately. Brokenwire is mitigated mainly at the RF/EMI layer (filtering, detection); adding TLS at the protocol level does not stop it.
Legal obligations and protection strategies
As EV charging approaches critical-infrastructure status, legal duties grow.
- Turkey: EPDK's Charging Service Regulation (in force since 2022, amended by later rules) imposes cybersecurity competency levels and audit obligations on charging service providers; periodic audits by authorized firms and reporting to EPDK are required.
- Payment security: PCI-DSS compliance is mandatory for systems handling card data.
- Automotive/lifecycle: ISO/SAE 21434 is the reference framework for cybersecurity engineering and supply-chain security in road vehicles.
- Periodic testing: an EVC penetration test (EV charging station pentest) has become standard practice to measure resilience and meet compliance.
Defense checklist
- Firmware signing: Secure Boot + Root of Trust; only signed firmware runs.
- Patch management: a measurable patch SLA for embedded kernel and components (regular inventory + CVE tracking).
- Network segmentation: L3 ACL between CMS and field devices; devices reach only required endpoints, never the open internet directly.
- Authentication: TLS + mutual certificates for OCPP; migrate to OCPP 2.0.1 security profiles where possible.
- Physical hardening: locks, sealing, a service-port access policy; charge-only cables.
- Monitoring: network traffic plus CPU/memory/response-time telemetry; grid-side anomaly detection for V2G.
Conclusion
The "simple box of electricity" narrative is dangerously misleading. A charging station is an OT system that fuses power electronics, embedded Linux, wireless PHY, and cloud management into a single physical and digital surface. Defense has to be reasoned about across all of those surfaces at once.
Thanks for reading; if you spot an error or have something to add, I am glad to correct it.
References
- CVE-2018-17182 — Linux kernel vmacache use-after-free (Project Zero, Jann Horn).
- CVE-2022-0878 — "Brokenwire", wireless DoS over CCS/HomePlug Green PHY.
- IEC 61851, IEC 62196, ISO 15118, OCPP 2.0.1, ISO/SAE 21434, PCI-DSS.
What do you think?
React to show your appreciation