OCPP security: what the first CPMS CVEs mean for operators

The CVEs affect specific products – their patterns affect the industry.

A CVE is always a statement about a named product and a defined version range. The records published in 2026 therefore do not mean that OCPP as a protocol is inherently insecure, nor do they automatically make DCS Charge or the NeLeSo Community Edition affected products. They do expose weakness classes that every CPMS and every OCPP ingress should be tested against.

The Open Charge Alliance summarises 47 CVEs across twelve backend providers in its Vulnerability Research Update. The striking point is not only the number, but the repetition of the same four failures: a charge point is accepted from its ID alone, authentication attempts are unrestricted, a second connection can displace an established session, or identifiers treated as credentials can be found publicly.

That defines our response to new advisories: we do not publish a casual “not affected” statement. We test the attack class at both OCPP entry points – the Broker and the terminating OCPP Server –, add regression tests and make the remaining compatibility mode visible.

Four CloudCharge CVEs form a complete attack chain.

CISA advisory ICSA-26-057-03 describes four vulnerabilities in the third-party CloudCharge service. Together they provide a clear example, progressing from discovering a station ID to taking over a connection. CISA reported no known public exploitation at publication, and the advisory did not document a vendor remediation.

A station ID is therefore exactly what its name says: an identifier. It is not a password. Knowing or guessing an OCPP path must not let a client impersonate a charge point or receive commands intended for it.

• CVE-2026-20781 · critical, CVSS 9.4: A known or discovered ChargingStationId is sufficient for impersonation because the WebSocket has no effective station authentication.
• CVE-2026-25114 · high, CVSS 7.5: Unrestricted authentication attempts enable brute force and denial of service.
• CVE-2026-27652 · high, CVSS 7.3: A new connection using the same predictable ID can displace the legitimate station and receive backend commands.
• CVE-2026-20733 · medium, CVSS 6.5: Authentication identifiers were publicly accessible through mapping platforms.

SteVe demonstrates the second boundary: a valid connection must not own everything.

CVE-2026-28230 affects SteVe through version 3.11.0 and a different, equally important protection layer. StopTransaction was processed from a sequential transactionId without additionally binding the transaction to its chargeBoxId. A different charge point could therefore stop a transaction it did not own. SteVe 3.12.0 includes the fix.

Connection authentication does not grant authority over every record. Transactions, meter values, EVSEs and connectors must remain bound to tenant and station on the server. The same rule applies in the opposite direction: a remote command may only reach the authenticated session of its intended station.

Our patch baseline: protection before the upgrade, not inside a later OCPP message.

We reviewed these attack classes for DCS Charge and the Community Edition at both the OCPP Broker and the direct OCPP Server. The security decision happens before the WebSocket upgrade, before a backend connection is opened and before a station enters the active session registry. A later Authorize message for an RFID or vehicle token is not station authentication.

Fresh Enterprise and hosted production installations start in Enforce mode. Existing installations start in Audit after the update so that an older device is not disconnected without warning. The local Community quickstart also starts deliberately in Audit while its simple default setup still uses ws://; internet-facing operation requires WSS followed by a switch to Enforce. The portal shows platform administrators the coverage, missing credentials and legacy exceptions. Off remains available as an explicitly unsafe emergency mode; even then, unknown station IDs are not auto-provisioned.

• Unknown station IDs are rejected by Broker and Server; an inbound OCPP path never provisions a station automatically.
• Enforce requires WSS/TLS and an individual Basic Auth password per station. Passwords are stored only as slow PBKDF2 hashes and are write-only in the portal.
• Failures are limited per source and station ID and recorded as security events without writing credentials to logs.
• A second connection cannot evict an active station. The newcomer is rejected, with an additional race guard in the upgraded session handler.
• Broker and internal OCPP Server use a short-lived, station-bound HMAC assertion with a nonce and replay protection.
• Global modes and station policies are stored and audited centrally so that multiple Broker instances use the same decision.

Legacy devices remain possible – but never invisibly insecure.

Not every installed station can use Security Profile 2 or 3 immediately. A global all-or-nothing switch would be operationally wrong: older devices would either fail, or the entire estate would remain at the security level of its least capable device. We separate a system-wide operating mode from an explicit policy for each station.

Audit evaluates every new connection as Enforce would, but initially does not block a violation. Firmware levels, missing passwords and incorrect URLs become visible. A legacy exception requires a preregistered station, a reason and an expiry date. Where a device can only use an unencrypted transport, it also belongs behind a private APN or VPN, a dedicated TLS tunnel, network allowlists and close monitoring. This is risk treatment, not security equivalent to WSS and individual authentication.

Off is intended only for a controlled incident or migration. It does not turn a station ID into a secret and it does not resist the CVE classes described here. The allowlist of registered IDs therefore remains active, and every return to Audit or Enforce belongs in the operational audit trail.

• Enforce: WSS/TLS and an individual station password are required during the handshake.
• Audit: the same evaluation and full visibility, without immediately interrupting older devices.
• Legacy exception: preregistered per station, justified, time-limited and protected by compensating network controls.
• Off: an available emergency mode that is explicitly not presented as secure steady-state operation.

Charge-point firmware is part of the security boundary.

A secure CPMS cannot repair vulnerable charge-point firmware. CVE-2026-4156 shows the opposite direction: a crafted OCPP message could trigger a memory error and ultimately root-level code execution on affected ChargePoint Home Flex devices; the vendor provided corrected firmware. Operators therefore need both a CPMS patch process and a model and firmware inventory with staged rollout.

For ABB Terra AC, ABB documents TLS 1.2 over WSS and Basic Auth for external OCPP backends in the 1.8 firmware line. From firmware 1.8.2, the inclusion of the AuthorizationKey in the HTTP handshake can also be controlled explicitly. This is more precise than saying “WSS only works from 1.8”: the decisive factors are device variant, firmware level, certificate trust and the actual backend configuration.

CVE-2025-5517 reinforces the firmware point for Terra AC: certain older variants could suffer memory corruption from crafted OCPP messages, and ABB identifies corrected 1.8.x versions for each variant. In brownfield projects we update such devices remotely in pilot groups, verify reconnect, WSS and authentication, then roll out site by site. Devices that still lack sufficient security features remain in a visible, expiring exception until replacement.

What operators should test now.

The first question is not “Does our CPMS support OCPP?”, but “How is a station authenticated unambiguously when it connects, and how is that identity preserved in every message?”. The answers can be demonstrated in a test environment with an unknown ID, an incorrect password, a duplicate connection and a command for a transaction owned by another station.

A Security Profile on a data sheet is not enough. The firmware and configuration actually deployed on every station matter. Mixed fleets therefore need a controlled transition in which compatibility remains visible and exceptions do not become an indefinite default.

• Are unknown station IDs rejected before the WebSocket upgrade?
• Is WSS active with an individual password or client certificate per station, rather than a fleet-wide shared password?
• Can a second connection displace the established station or receive its commands?
• Do rate limits cover unknown IDs and incorrect credentials at the central ingress and at every Broker instance?
• Are transactions, meter values and remote commands bound on the server to tenant, station, EVSE and connector?
• Are Authorization headers, tokens, signed URLs and other secrets removed from logs and support exports?
• Which legacy exceptions exist, why, until when and with which network segmentation?
• Which models and firmware levels are deployed, and how are security updates piloted and verified?

Security remains an operational process.

The newly published CVEs are not a one-off event. They mark the beginning of more systematic scrutiny of charging infrastructure. We will update this assessment when new advisories affect the architecture or patch baseline, and we run the same attack-class tests in the Enterprise and Community pipelines.

The robust target remains tiered: Security Profile 2 – WSS plus an individual password – is the compatible production baseline. Security Profile 3 with client certificates is the stronger option for capable devices. Where neither is possible, the exception must become smaller, more visible and shorter – not the security policy of the entire platform weaker.