A newly disclosed weakness in the ISO 15118 electric‑vehicle charging stack lets an attacker manipulate the
Signal Level Attenuation Characterization (SLAC) exchange used to pair a vehicle and charger, creating a practical man‑in‑the‑middle (MitM) pathway between EV and EVSE that affects implementations of
ISO 15118‑2 and has been tracked as CVE‑2025‑12357. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) republished this finding as an ICS advisory and the researcher credited for the report is Mark I. Johnson of Southwest Research Institute; CISA’s advisory documents a high impact on confidentiality and availability and calculates both CVSS v3 and v4 base scores for the finding.
Background
ISO 15118 is the international standard defining Vehicle‑to‑Grid and EV‑to‑charger communications. The body of work is split across parts:
ISO 15118‑2 (network and application protocol requirements for earlier versions),
ISO 15118‑3 (physical and data link layer details, including power‑line communication), and the newer
ISO 15118‑20 which consolidates and tightens several security requirements. In practice, ISO 15118‑2 remains widely deployed across many EVs and chargers; ISO 15118‑20 raises the security bar by requiring TLS 1.3 and stronger certificate and cipher expectations. At the lower layers of the ISO 15118 stack many implementations use
HomePlug Green PHY (HPGP) power‑line communications (PLC) to carry the initial discovery and the high‑level ISO messages. Within that PLC layer the
SLAC process (Signal Level Attenuation Characterization) identifies which physical EVSE a vehicle is connected to, evaluates channel quality, and establishes the PLC link so ISO 15118 messages can be exchanged. SLAC is therefore a short, timing‑sensitive, link‑layer pairing step that precedes the higher‑level network session. Practical tooling and open implementations — including test utilities that emulate EV and EVSE SLAC exchanges — demonstrate this architecture in real devices. CVE‑2025‑12357 centers on that SLAC pairing phase: by supplying forged or spoofed SLAC measurements an attacker can
convince the EV and EVSE they are paired to each other while actually routing or intercepting subsequent traffic — a classic MitM posture created at link layer before any application‑layer protections are negotiated. CISA’s advisory highlights the risk, describes the attack vector as adjacent (non‑internet) exposure, and notes the vulnerability may be exploitable by wireless or near‑field techniques under specific conditions.
What the advisory says — concise summary
- Affected component: ISO 15118‑2 (Network and Application Protocol Requirements), specifically the SLAC/PLC pairing used in the discovery phase.
- Vulnerability: Improper Restriction of Communication Channel to Intended Endpoints — SLAC responses can be spoofed to misassociate EV and EVSE and enable MitM.
- Assigned identifier: CVE‑2025‑12357.
- Severity: CISA reported a CVSS v3 base score of 8.3 and also provided a CVSS v4 base score of 7.2 with vector strings included in the advisory.
- Exploitability and scope: The advisory classifies the issue as an adjacent‑network (not purely Internet‑remote) risk and explicitly notes the possibility of exploitation via close‑proximity electromagnetic coupling or induction in some deployments — producing a MitM between vehicle and charger. No confirmed public exploitation was reported at the time of CISA’s notice.
- Researcher: Mark I. Johnson of Southwest Research Institute reported the vulnerability to CISA.
This advisory is targeted at equipment vendors, operators of charging infrastructure, and asset owners in the transportation and critical infrastructure sectors; the impact is global wherever ISO 15118‑2 EVSE/EV pairings are in use.
Why SLAC matters: technical context
SLAC runs at the PLC link layer (HomePlug Green PHY) and is the mechanism that establishes which EVSE the EV is physically connected to and whether the PLC channel is usable. SLAC includes measured signal‑level exchanges and a handshake that associates a unique identifier for the pairing session; subsequent IP/TCP/TLS (if present) flows rely on that pairing to be correct.
Because SLAC is a link‑layer protocol designed for the physical pairing, it runs
before higher‑level protections like TLS are negotiated in many ISO 15118‑2 flows. That ordering creates a narrow but powerful attack window: if an attacker influences SLAC outcomes, the EV and EVSE may proceed with what they both believe to be a legitimate physical link while the attacker sits in the middle of the PLC or adjacent medium. Several practical open‑source tools used in testing and emulation of ISO 15118 (for example utilities that emulate EV/EVSE SLAC sequences) demonstrate how link‑layer behavior can be observed and manipulated in lab settings; HomePlug Green PHY vendors and implementers document SLAC as the explicit pairing mechanism. Key technical consequences of a successful SLAC manipulation:
- Session interception: IP packets between EVCC (vehicle-side controller) and SECC (station controller) can be captured or relayed.
- Message injection: Attacker can insert malformed or crafted ISO 15118 messages before TLS (if used) is established.
- Downgrade and reconnaissance: A MitM at link layer can attempt TLS downgrade, observe certificates offered during subsequent negotiation, or probe for available authentication modes.
- Supply‑chain implications: Compromised charging sessions can be leveraged for credential or billing fraud when Plug & Charge workflows are present.
These outcomes are not theoretical vulnerabilities in the abstract — they directly target the precise moment when vehicle and charger
trust that their physical pairing is valid.
How ISO 15118 revisions change the security posture
One of the most operationally relevant parts of CISA’s advisory is the parallel recommendation to
implement TLS and certificate chaining, and the reminder that
ISO 15118‑20 makes TLS mandatory for native sessions. In contrast,
ISO 15118‑2 historically required TLS only for specific modes (notably Plug & Charge certificate installation) while leaving External Identification Means (EIM) flows able to operate without full TLS in some deployments.
Independent technical reviews and protocol documentation show that ISO 15118‑20 tightens the transport layer and mandates TLS 1.3 with stronger cipher suites and mutual authentication across more use cases. Implementers moving from 15118‑2 to 15118‑20 should expect:
- Mandatory TLS 1.3 for native sessions, with strong cipher suites and mutual authentication.
- Clearer expectations for certificate chain handling, certificate sizes, and device memory requirements to store certificate chains.
- Better guidance for secure key storage using HSMs or secure elements.
Those protocol advances materially reduce the risk surface at the application transport layer — but they do not retroactively fix link‑layer SLAC weaknesses in existing ISO 15118‑2 installations unless vendors implement layered mitigations.
Verification of key claims and numbers
- The vulnerability identifier CVE‑2025‑12357 and the summary CVSS values (CVSS v3 = 8.3, CVSS v4 = 7.2) are reported in the CISA advisory text supplied to WindowsForum and republished in CISA’s body of advisories. These figures are quoted directly from the advisory.
- The SLAC protocol’s role as a HomePlug Green PHY link‑layer pairing mechanism and its specification in ISO 15118‑3 / HomePlug Green PHY is corroborated in multiple technical sources and test suites that describe SLAC as the channel‑quality and pairing step used to select the proper EVSE and create the PLC logical network.
- The statement that ISO 15118‑20 requires TLS for all native sessions and tightens cipher/certificate rules is supported by recent technical overviews and vendor documentation explaining the migration to mandatory TLS 1.3 and stronger cipher suites in 15118‑20. Implementers and infrastructure owners should treat 15118‑20 as the security target to migrate toward.
- The advisory’s claim that exploitation may be possible via wireless, close‑proximity electromagnetic induction is stated in CISA’s advisory; however, independent, public technical reproductions of a reliable electromagnetic induction exploit against SLAC are not apparent in the public research literature at the time of publication. That claim should therefore be treated with caution and prioritized for further testing and validation by vendors and labs.
Where explicit external public proof‑of‑concepts exist for parts of SLAC‑level attacks (link‑layer manipulations using PLC tools), academic and engineering testbeds have demonstrated how SLAC and PLC behavior can be observed and emulated; the leap from emulation to
wireless induction exploitation requires specialized hardware and is not fully documented in independent open literature at present. Organizations should not dismiss the advisory’s proximity‑based warning, but they should also seek lab validation from vendors or trusted test labs to determine practical exploitability in their deployments.
Practical risk evaluation — who should care and why
- Charging network operators and site owners: Any deployment where EVSE and EV exchange ISO 15118‑2 messages over PLC or other adjacent mediums is in scope. Public fast‑charging stations, workplace chargers, and fleet depots are particularly sensitive because an attacker with local access or equipment could intercept multiple sessions or harvest credential artifacts.
- Vehicle manufacturers and EV software integrators: Vehicles that trust SLAC pairing without additional endpoint verification are a potential target for session interception, which could lead to unauthorized charging behavior or privacy leakage. Implementers must verify whether vehicle stacks perform end‑to‑end authentication that refuses sessions where link‑layer pairing appears suspicious.
- Utilities and grid operators: Manipulation of charging sessions can influence billing, metering, and potentially grid‑service interactions when V2G or aggregated behavior is present.
- Security teams and integrators: The adjacency of the attack vector means that traditional firewall‑centric mitigations (designed for IP exposure) are not sufficient; visibility into PLC and physical connection health is needed.
CISA’s advisory explicitly recommends defensive measures that are common to ICS and OT hardening programs: minimize network exposure, isolate EVSE and control networks behind firewalls, use secure remote access for management, and perform impact analysis prior to deploying mitigations — all sensible operational guardrails.
Immediate, prioritized mitigations (practical checklist)
The following steps are ordered by immediacy and impact for operators managing EVSE fleets or private charging sites.
- Inventory and map exposures
- Document all EVSE that implement ISO 15118‑2, the transport used (PLC/HomePlug, TCP), and whether TLS is enforced for sessions.
- Enforce TLS where possible
- For devices that support TLS in ISO 15118‑2, enable and require it; for new deployments prefer ISO 15118‑20 capable stacks that mandate TLS 1.3 and mutual authentication.
- Apply certificate chaining and strict validation
- Ensure EVSE and backend services validate full certificate chains, perform revocation checks (OCSP/CRL), and store private keys in secure hardware (HSM or secure element) when available.
- Network segmentation and isolation
- Place EVSE management and billing networks on separate VLANs, apply firewall rules between IT and OT networks, and block unnecessary outbound services from EVSE. CISA’s standard ICS mitigations map directly here.
- Disable unneeded discovery protocols
- Where SLAC/PLC discovery is not required (for example, fenced fleet depots that can use wired IP connectors), disable PLC discovery or require physical pairing procedures.
- Increase monitoring and detection
- Add logging and anomaly detection for SLAC/PLC events where devices expose telemetry; flag unexpected pairing switches or repeated pairing attempts. 7. Vendor coordination and patching
- Contact EVSE and vehicle vendors for firmware updates or vendor‑supplied mitigations. Treat vendor responses as part of risk acceptance if patches are unavailable.
For defenders with limited operational flexibility, the two quickest wins are (a) enforce TLS or move to ISO 15118‑20 capable stacks where possible and (b) segment EVSE networks so any local MitM cannot pivot into core business or billing systems.
Longer‑term technical remedies and engineering changes
- Move to ISO 15118‑20 or equivalent: The newer revision requires TLS 1.3 by default and adopts stronger certificate and cipher options that remove many classically abused transport‑layer weaknesses. Migration planning must account for certificate sizes, memory, and HSM requirements.
- Harden SLAC and link‑layer logic: Vendors should consider adding cryptographic binding between SLAC pairing and higher‑level session negotiation (for example, a short authenticated token created at SLAC and consumed in the first TLS handshake). That would raise the bar by ensuring link‑layer pairing cannot be trivially spoofed without possession of session secrets. This is a design change that requires standardization discussion or vendor alignment.
- Secure hardware for key storage: Deploy secure elements or HSMs in both EV and EVSE to protect private keys and prevent extraction in field devices.
- Incident response and forensic readiness: EVSE vendors and operators should instrument logging for SLAC pairing measurements and keep forensics capable of reconstructing pairing anomalies.
These longer‑term defenses require coordination across vehicle OEMs, EVSE vendors, and charging network operators; standards‑level fixes are preferable but can take time to reach the installed base.
Known gaps and caveats — what remains uncertain
- Electromagnetic‑induction exploitability: The advisory warns that in certain deployments an attacker might exploit SLAC using wireless (close proximity) electromagnetic induction. Public, independently verified PoCs that reproduce a reliable wireless induction exploit against production SLAC implementations are not widely available in the open literature. Until vendor labs or independent researchers produce reproducible demonstrations, the wireless/induction claim should be treated as plausible but not yet proven in broad practice. Operators should act conservatively but also request vendor test evidence specific to their hardware models.
- Vendor patch availability: At the time of the advisory, vendors vary in their response timelines. Some will issue firmware updates quickly; others may require hardware or substantial stack updates. Where a vendor does not or cannot issue a patch, isolation and replacement planning are the practical options.
- Scope beyond PLC implementations: SLAC is most used with HomePlug Green PHY PLC. Implementations that use alternative physical layers or direct TCP/IP links may be unaffected by this specific SLAC manipulation; asset owners should verify transport details per unit.
What IT and Windows administrators should do now
- Treat EVSE management hosts and PC‑based charging station controllers as engineering endpoints and apply standard Windows endpoint hardening: patching, EDR, privileged access restrictions, and least‑privilege jump servers for maintenance.
- Ensure management plane access to EVSE and backend systems is not routed over the public internet; use segmented VPNs only when necessary and ensure endpoints connected over VPN are hardened and patched.
- Coordinate with OT teams: this is a cross‑discipline problem where IT controls (segmentation, NAC, endpoint protection) and OT vendor actions (firmware and protocol fixes) must work together. CISA’s standard ICS defense guidance applies in full.
Conclusion — an operational call to action
CVE‑2025‑12357 exposes a structural weakness: link‑layer pairing (SLAC) is a narrow but critical trust boundary in EV charging stacks, and manipulation of that boundary can yield classic MitM outcomes even before application‑level protections are negotiated. The disclosure and CISA’s advisory are an urgent reminder that partial adoption of standards (for example, running ISO 15118‑2 without TLS or without strict certificate handling) leaves real attack windows in the field.
The immediate, pragmatic roadmap is clear:
- Treat the advisory as operational intelligence: inventory, segment, and require TLS where possible.
- Prioritize firmware and vendor coordination to obtain patches or mitigations.
- Accelerate plans to migrate to ISO 15118‑20‑compatible stacks where practical, and insist on secure key storage and full certificate validation in procurement contracts.
At the systems level, defenders need to pair
protocol hardening (TLS, certificate chains, HSMs) with
network and physical controls (segmentation, monitoring, and limited physical access). That multi‑layer approach — marry secure transport to hardened link‑layer logic and operational controls — is the only practical path to reduce exposure while vendors and standards bodies work toward long‑term protocol improvements.
Organizations that operate EV charging infrastructure should treat this advisory as an actionable security incident: inventory affected assets, apply the mitigations above, and demand from vendors the evidence and firmware that prove the issue is closed in your specific fleet. The clocks ticks differently for high‑velocity attackers in adjacent spaces — prioritize defense now, validate fixes in the lab, and move institutional practices toward the more secure defaults embedded in ISO 15118‑20.
Source: CISA
International Standards Organization ISO 15118-2 | CISA