Jherrod ThomasThe Lion of Functional Safety™

June 2, 2026 · 14 min read

IEC 62443-4-2ISO 15118 / OCPPCWE-122

When the Charger Was the Conduit

On May 26, 2026 CISA republished an ABB PSIRT advisory as ICSA-26-146-01, warning operators of the ABB Terra AC Wallbox that a single malformed OCPP message can pollute heap memory on the charger and rewrite the flash that holds its firmware. ABB rates the CVSS at 6.8. The deployment footprint — commercial facilities, critical manufacturing, energy, transportation — is global. The interesting sentence is not in the vulnerability description; it is in the mitigating factors. Read it twice and the engineering story comes into focus.

I have spent most of the last month writing about cracked rotor shafts, mis-milled fuselage panels, and a pacemaker that latched into a fail-safe state nobody actually verified. This one is different — it is an industrial cybersecurity story that the automotive world keeps trying to dodge. The Level-2 AC wallbox in the parking garage is not a "car." It is an industrial control component that happens to terminate a power conductor on one side and a Charging Station Management System (CSMS) socket on the other. It is governed by IEC 62443. And the headline is what happens when input validation is treated as a CSMS problem instead of a charger problem.

Public record. Standards lens. Worked snippet. Derived requirements. What the headline actually tells us.

1. The public record

On May 26, 2026, CISA released ICS advisory ICSA-26-146-01, "ABB Terra AC," a verbatim republication of ABB PSIRT advisory 9AKK108471A8948 (CISA ICSA-26-146-01). The CSAF JSON for the advisory is mirrored in the CISA repository on GitHub for machine consumption (cisagov/CSAF, icsa-26-146-01.json). Initial vendor release was October 20, 2025; the May 26, 2026 republication is the broad-distribution event that pulled the story into the asset-owner channel where most operators actually read it.

The affected products are the global SKUs of the ABB Terra AC Wallbox — a Level-2 AC EV charger broadly deployed in commercial parking facilities, fleet depots, and home charging. The advisory enumerates them:

The CVE record is CVE-2025-5517 (CVE-2025-5517). CISA assigns CVSS v3.1 base score 6.8 (Medium) with vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H. The mapped weakness is CWE-122 — Heap-based Buffer Overflow (CWE-122). The advisory's plain-English summary deserves to be quoted in full: "An attacker who successfully exploited this vulnerability could cause the pollution of heap memory which potentially takes remote control of the product and performs a write operation to the flash memory to alter the firmware behavior."

The originating research is from Itai Shmueli of SaiFlow, who walked through the parser bug and its exploitation surface in a public write-up (SaiFlow, ABB Terra AC Buffer Overflow Vulnerability (CVE-2025-5517)). SaiFlow had previously published two earlier authentication-bypass CVEs on the same family (CVE-2023-0863 and CVE-2023-0864), so this is the third independently-discovered CVE class on the Terra AC platform in twenty-four months (SaiFlow, ABB Terra AC Improper Authentication). Independent trade-press coverage on the May 2026 republication is in ISSSource (ISSSource, Another Fix for ABB EV Charger) and a technical summary on Windows News (Windows News, CVE-2025-5517: Heap Overflow in ABB Terra AC EV Chargers).

Mechanism, in the advisory's own words: "the firmware did not limit the length of OCPP field in certain case." A malicious or hijacked CSMS can send an OCPP payload — the most-cited candidate is a BootNotification with an oversized vendor or model field — and the charger's parser writes past the end of an allocated heap buffer, corrupting adjacent control data and opening a path to arbitrary code execution and a firmware-flash write. Once the charger's firmware is rewritten, the device is the attacker's.

Now the part that earns this post. The CISA advisory lists exactly one workaround: "Use https (TLS) as basic communication foundation between charger and OCPP backend instead of http." And it lists one mitigating factor: "hackers must hijack CSMS first... OR the way to OCPP backend is unsafe itself (http) which can cause any kind of attack behavior and known as a common knowledge." Translate that out of vendor-advisory voice and what it says is: the bug is exploitable for free in any deployment that runs OCPP over plain WebSocket without TLS, which is OCPP 1.6 Security Profile 0 — and Security Profile 0 is the default of a great many real installations today.

2. The standards lens

The instinct, on reading a CVSS-6.8 vendor advisory, is to file the work product as "patch the charger." That is necessary and insufficient. The actual failure crosses three standards layers, and naming each one tells you which artifact was missing.

IEC 62443-4-2 — Technical security requirements for IACS components. Terra AC is an Embedded Device (EDR) in 62443 terms. CR 3.5 — Input validation — requires the component to validate the syntax, length, and content of inputs received over external interfaces before they reach a parser that can corrupt internal state. A 62443-4-2 EDR conformance review with even modest rigor would have asked, of the OCPP parser, "what is the bounded length of each field, and where does the parser enforce it?" If the answer is "it does not," that is a CR 3.5 finding, not a CVE. The CVE is the symptom of the missing CR 3.5 control.

IEC 62443-4-1 — Secure product development lifecycle. Practice 5 (SVV) is where this bug should have died.

That all three SVV sub-practices missed the same parser is not bad luck; it is the SVV section of the SDL being underspecified for the OCPP attack surface.

IEC 62443-3-3 — System security requirements and security levels. The charging-site integrator owns this layer. The advisory's TLS workaround is the integrator's job to deploy, and 62443-3-3 names the requirement:

For an EVSE site to claim Security Level 2 under 62443-3-3, those three SRs must be met; for SL 3, they must be met with attacker-active threat modeling. The ENCS EV-311-2022 profile — Security requirements from IEC 62443 for procuring EV charging stations — codifies this allocation as a procurement-language template that European DSOs and CPOs already use (ENCS EV-311-2022 (PDF)).

OCPP Security Profiles are the operational lever. OCPP 1.6 defines four profiles, numbered 0 through 3 (Open Charge Alliance, Understanding OCPP Security Profiles):

| Profile | Auth | Transport | Use today | |---|---|---|---| | 0 | None | Plain ws:// | Lab and many production sites | | 1 | HTTP Basic | Plain ws:// | Common but insecure | | 2 | HTTP Basic | TLS wss:// | Acceptable minimum | | 3 | Mutual TLS (client cert) | TLS wss:// | Required minimum for SL 2+ |

OCPP 2.0.1 keeps the same profile model but mandates TLS 1.3 in Profile 3 — a meaningful improvement after years of downgrade-attack research against TLS 1.2 OCPP deployments (Springer, OCPP in the spotlight: threats and countermeasures). The ABB advisory is, in effect, telling integrators that if they have not migrated past Profile 0 or 1, CVE-2025-5517 is not their only problem; it is just the one with a CVE number this month.

ISO 15118 — V2G communication. A clarification worth making, because integrators conflate it. ISO 15118 governs the vehicle-to-charger leg — the Plug and Charge handshake, the certificate-based mutual authentication between EV and EVSE. OCPP governs the charger-to-CSMS leg. CVE-2025-5517 sits entirely on the OCPP leg. But the certificate model ISO 15118-2 and 15118-20 use — mutual TLS with a PKI rooted in the V2G Root CA — is the same model OCPP Security Profile 3 uses on the other side of the charger. If you can run mTLS on the south side, there is no engineering reason you cannot run it on the north side. The standards already agree.

NIST SP 800-82 Rev. 3 and the CRA. EVSEs are OT under NIST SP 800-82 Rev. 3's scope, and under the EU NIS2 Directive transposition they are critical-infrastructure components. The EU Cyber Resilience Act, in force since December 2024, requires products with digital elements to maintain a vulnerability-handling process and an SBOM. CVE-2025-5517's eight-month gap between initial PSIRT release (October 20, 2025) and broad CISA republication (May 26, 2026) is exactly the kind of disclosure latency the CRA is intended to eliminate.

3. A worked snippet — zone-and-conduit, OCPP payload, and the fault tree

Because this is a 62443-flavored story, the right artifact is an IEC 62443-3-2 zone-and-conduit diagram for a typical AC charging site, a worked OCPP BootNotification (benign and malicious), and a fault tree.

Zone-and-conduit model

+---------------------------------------+        +-------------------------+
|  Zone: Charging Bay (SL-T 2)          |        |  Zone: CSMS Cloud       |
|                                       |        |  (SL-T 3)               |
|   [ EV ] --15118 mTLS-- [ EVSE ]------+--C1----+-->  [ CSMS ]            |
|                          Terra AC     |  OCPP  |     OCPP / API          |
|                          (EDR)        | wss/ws |                         |
+---------------------------------------+        +-------------------------+
                                                          |
                                                          |   C2 (REST/API)
                                                          v
                                                  +-------------------+
                                                  | Zone: CPO Back    |
                                                  | Office (SL-T 2)   |
                                                  +-------------------+

Conduit C1 — Charger ↔ CSMS:
   Required: Security Profile 3 (wss + mTLS, TLS 1.3 preferred).
   Observed in many deployments: Security Profile 0 (plain ws).

Conduit C2 — CSMS ↔ Back office:
   Required: mTLS, signed API tokens, audit log.

OCPP BootNotification — benign vs. malicious

A well-formed BootNotification payload, OCPP 1.6J, is bounded by the protocol spec. The two text fields that matter for CVE-2025-5517 are chargePointVendor (20 character max per OCPP) and chargePointModel (20 character max). A correct parser refuses anything longer.

[2, "msg-001", "BootNotification", {
  "chargePointVendor":   "ABB",
  "chargePointModel":    "TerraAC-W22",
  "chargePointSerialNumber": "5K1234567",
  "firmwareVersion":     "1.8.32",
  "iccid":               "",
  "imsi":                "",
  "meterSerialNumber":   "M-998877",
  "meterType":           "AC-3P"
}]

The attacker's variant — passed by a hijacked or rogue CSMS — replaces one of those fields with a string thousands of bytes long. A parser without a CR 3.5 length check copies it into a fixed heap buffer and overruns it.

[2, "msg-001", "BootNotification", {
  "chargePointVendor": "AAAAAAAA... (8192 bytes) ...AAAA",
  "chargePointModel":  "TerraAC-W22"
}]

That is the entire mechanism. There is no novel cryptographic trick, no zero-day in a TLS stack, no chained gadget. It is one missing strnlen and one missing length comparison.

Fault tree — heap memory corruption on Terra AC

                          [ TOP: Terra AC heap corrupted ]
                                       OR
              +------------------------+----------------------+
              |                                               |
   [ Oversized OCPP field accepted ]              [ Forged frame crosses conduit ]
                AND                                            OR
        +-------+-------+                          +-----------+-----------+
        |               |                          |                       |
[ CR 3.5 input    ] [ Parser writes        ] [ Plain ws://          ] [ CSMS itself
  validation         past heap buffer  ]      conduit (Profile 0) ]   hijacked ]
  absent ]
        |               |                          |                       |
   62443-4-1       SVV-3 fuzzing               62443-3-3            62443-3-3 SR 1.1
   SM-7 not        absent                       SR 3.1 / 4.1         (mutual auth)
   enforced                                      not met              not met

The tree is deliberately blunt about it. Either branch under the top OR-gate is sufficient. Plug the input-validation hole on the charger and the bug is dead even on a plaintext conduit. Plug the conduit (Profile 3 mTLS) and the bug stays dormant unless the CSMS itself is compromised. Plug both and you have what 62443 calls defense in depth.

4. Derived requirements (excerpt)

Five traceable cybersecurity requirements drop straight out of the above. IDs are stable; tags are 62443/CWE; rationale points back at the artifact that should already exist.

| ID | Requirement | Allocated to | Trace | |---|---|---|---| | CSR-EVSE-031 | The EVSE shall enforce a bounded maximum length on every OCPP message field defined in OCPP-J 1.6 §7 and OCPP 2.0.1 §2.5, and shall reject and log any frame whose declared or actual field length exceeds the bound. | Charger firmware (Terra AC EDR) | IEC 62443-4-2 CR 3.5; CWE-122; CVE-2025-5517 | | CSR-EVSE-032 | The EVSE shall fail closed on any OCPP message that fails parser validation, entering a defined fault state that suspends new charging sessions and preserves any active session through a graceful stop. | Charger firmware | IEC 62443-4-2 CR 3.6; FR 7 (Resource Availability) | | CSR-EVSE-033 | The EVSE shall reject OCPP connections that do not present a valid client certificate chained to the site's designated V2G or CPO root, i.e., OCPP Security Profile 3, with TLS 1.3 where supported and TLS 1.2 with approved cipher suites as a transition floor. | Charger firmware; site network policy | IEC 62443-3-3 SR 3.1, SR 4.1; OCPP 1.6 SP 3 | | CSR-EVSE-034 | The product supplier shall publish a CycloneDX or SPDX SBOM for each released firmware build, shall subscribe to the upstream vulnerability feeds for every named third-party component, and shall issue a security patch within 60 days of an assessed exploitable CVE in any such component. | ABB PSIRT / SDL | IEC 62443-4-1 SM-9, DM-1, DM-3, SUM-5; CRA Art. 13/14 | | CSR-EVSE-035 | The CSMS operator shall enforce mutual TLS to every connected EVSE, shall rotate per-charger client certificates on a defined schedule, and shall log every OCPP message rejected by parser-side validation for SOC review. | CSMS / CPO back office | IEC 62443-3-3 SR 1.1, SR 1.2, SR 2.8, SR 6.1 |

A charger product file that already contained CSR-EVSE-031 and CSR-EVSE-033 would have made CVE-2025-5517 a one-line regression test rather than a CISA advisory.

5. What the headline really tells us

The headline reads "Heap overflow in EV charger, patch available, CVSS 6.8." The work product the operator needs to write is shorter: we shipped a Level-2 AC charger that trusts the cable.

Every CR-3.5-compliant component begins with the assumption that the conduit is hostile. The Terra AC OCPP parser did not. Its safety-relevant invariants — bounded fields, fail-closed on parse error, integrity of the firmware-update path — were guarded only by the assumption that the CSMS at the other end of the WebSocket was honest and that the network between them was private. Neither assumption holds in a 2026 charging site. Half of the deployed CSMS instances are multi-tenant SaaS reachable from the public internet; the other half are sitting on industrial VLANs that share switches with PoE cameras, building-automation controllers, and a small number of contractors with VPN credentials they should not have.

The interesting engineering question is not "how did the parser miss the length check." The interesting question is which other components in the same product family terminate the same OCPP socket and inherit the same assumption. SaiFlow's earlier 2023 CVEs on the same Terra AC family were authentication-bypass class. This 2025/2026 CVE is parser class. Two failure classes on the same north-side interface in twenty-four months is the signal. The signal points at an SDL whose threat model for the OCPP conduit was less complete than the one for the V2G (15118) conduit on the south side. Those two conduits deserve identical scrutiny. The EV does not care which side breaks first.

Sources

— Jherrod Thomas, The Lion of Functional Safety™