CVE-2026-20781: The Charger That Only Had To Say Its Own Name

A CVSS 9.4 in EV-charging infrastructure where "authentication" turned out to mean typing a station ID into a URL. CWE-306, network-reachable, no patch — because the vendor never picked up the phone.

A note on what I actually reviewed

Let me be honest about the evidence up front, because it changes how you should read everything below. The repository attached to this CVE is cisagov/CSAF — CISA's machine-readable advisory store. Cloning it (git clone --depth 80, 11,485 files) and grepping for ocpp, websocket, or cloudcharge across every .py/.js/.ts/.go file returns nothing. There is no CloudCharge source here, no fix commit to git show, and therefore no flawed function to quote line-by-line and no code property graph (CPG) to run a source→sink flow against. CloudCharge (product site cloudcharge.se; support/contact at cloudcharge.tech) is closed-source, and the advisory's own remediation field records that "CloudCharge did not respond to CISA's request for coordination."

So this is not a patch-diff post. It's an architecture-level forensic read of a missing mechanism, grounded in (a) the CSAF advisory I can cite verbatim and (b) the public OCPP-J protocol the product implements. Where I'm reasoning from the open OCPP standard rather than from CloudCharge's bytes, I say so.

The advisory in plain English

From csaf_files/OT/white/2026/icsa-26-057-03.json @ 3250da4, L213–L221:

"cwe": { "id": "CWE-306", "name": "Missing Authentication for Critical Function" },
"notes": [{
  "category": "summary",
  "text": "WebSocket endpoints lack proper authentication mechanisms ... An unauthenticated
   attacker can connect to the OCPP WebSocket endpoint using a known or discovered charging
   station identifier, then issue or receive OCPP commands as a legitimate charger."
}]

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L — base 9.4. Decode the vector and the whole story is in the prefix: AV:N (across the internet), AC:L (no special conditions), PR:N (no privileges), UI:N (no victim needed). The only "secret" in the entire trust model is the charging-station identifier, and CVE-2026-20733 in the very same advisory bundle (L427) cheerfully notes those identifiers are "publicly accessible via web-based mapping platforms." The credential and its disclosure shipped in the same PDF.

Where authentication was supposed to live

To see what's missing you have to know what OCPP-J expects. OCPP — the Open Charge Point Protocol — runs its JSON variant over a WebSocket. A charge point opens the connection to its Charging Station Management System (CSMS) at a URL whose final path segment is the station's identity, with ocpp1.6 (or ocpp2.0.1) offered as the WebSocket subprotocol. That path segment is an identifier, not a credential — exactly like a username with no password column next to it.

The Open Charge Alliance was painfully aware of this. The OCPP-J security guidance is explicit that the identity in the URL must be bound to a separate secret: either HTTP Basic authentication carrying a per-charger key on the upgrade request, or — better — a TLS client certificate, so the WebSocket handshake itself proves the charger is who the URL claims. The identifier answers "who do you say you are?"; the Basic-auth password or client cert answers "prove it."

CVE-2026-20781 is what happens when a backend implements the first question and forgets the second. The station identifier is treated as sufficient proof of identity. There is no Authorization: Basic check, no client-cert validation, no shared secret — the URL is the whole handshake.

Why the check was insufficient — because there was no check

Think of the WebSocket upgrade as a function whose tainted source is the HTTP request the attacker fully controls: the request path (carrying the station ID), the headers, the Sec-WebSocket-Protocol. The dangerous sink is the backend's session registry — the moment it binds this socket to a station identity and starts routing real OCPP commands (BootNotification, Authorize, StartTransaction, MeterValues, remote Reset) to and from it.

In a correct implementation there's a gate between source and sink: validate a credential bound to that identity before the socket is registered. The advisory's finding is that the path from source to sink has no gate at all. Whatever station ID the attacker puts in the URL is the station they become. That's the entire defect: an unauthenticated input flows straight into a privileged session binding.

Two sibling findings in the same advisory confirm the registry sink is as fragile as the front door:

• L358 (CVE-2026-27652): the backend keys sessions purely on the station identifier and "allows multiple endpoints to connect using the same session identifier ... the most recent connection displaces the legitimate charging station and receives backend commands intended for that station." So impersonation isn't just additive access — the newest socket shadows the real charger. Last writer wins.
• L289 (CVE-2026-25114): no rate limiting on the WebSocket auth path, so even where a guess is needed, nothing slows it down.

Stack them: identifiers are public (20733), no secret gates the bind (20781), the newest connection evicts the genuine charger (27652), and nothing throttles attempts (25114). Four CVEs that individually look like "harden later" tickets compose into full station impersonation against live charging infrastructure. The integrity impact (I:H) is the genuinely scary half — a shadow charger can feed the backend fabricated MeterValues and transaction events, corrupting the billing and telemetry the operator believes is ground truth.

What a fix would change

There's no commit to show, so here's the shape of the correction the protocol already specifies. The bind-to-session step must be made conditional on a per-charger secret presented during the upgrade:

• HTTP Basic auth on the WebSocket handshake, carried over TLS (wss://) — OCPP Security Profile 2, with a unique, rotatable password per station. The identifier names the charger; the password proves it. Note that Basic auth over bare ws:// (Security Profile 1) is not a fix: it ships the per-charger password in the clear to any network observer. Profile 2 (TLS + Basic) is the floor.
• Mutual TLS / client certificates — OCPP Security Profile 3 — so the handshake cryptographically establishes identity and the URL segment becomes a routing hint rather than an authority.
• Reject duplicate session binds for an already-connected identity instead of letting the newest socket evict the incumbent (closes the 27652 shadowing path).
• Rate-limit and lock out repeated auth failures per source and per identity (closes 25114).

None of this is exotic. It's in the spec. It just wasn't switched on.

The lesson

CWE-306 is boring in the way that load-bearing walls are boring: nobody photographs them until one is missing. The recurring failure here is conflating identification with authentication — treating a name the system needs anyway (a station ID, a username, an account number) as if knowing it were proof of being it. The moment that identifier is enumerable — and in OT, asset IDs are always enumerable, frequently printed on the side of the unit or plotted on a public map — your "auth" is a directory listing.

For anyone building over OCPP or any device-to-cloud WebSocket fabric: the upgrade request is an untrusted source, the session registry is a privileged sink, and the only thing that makes the wire safe is a secret on the handshake that the URL can't supply by itself. Read your own protocol's security annex. The Open Charge Alliance wrote the gate; CloudCharge's backend just never built it. And when a coordinator like CISA calls about your EV chargers and you let it go to voicemail, the CVE gets published anyway — without your patch in it.

References

• CISA ICS Advisory ICSA-26-057-03: https://www.cisa.gov/news-events/ics-advisories/icsa-26-057-03
• CSAF advisory JSON (reviewed source), pinned: https://github.com/cisagov/CSAF/blob/3250da46c99cfa6473e48957a313e747e52bbdaf/csaf_files/OT/white/2026/icsa-26-057-03.json#L213
• CSAF advisory JSON (develop branch): https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-057-03.json
• CVE-2026-20781 record: https://www.cve.org/CVERecord?id=CVE-2026-20781
• CWE-306, Missing Authentication for Critical Function: https://cwe.mitre.org/data/definitions/306.html
• CloudCharge vendor contact (per CISA remediation note): https://cloudcharge.tech/support/contact/