CVE-2026-20781 is a critical missing authentication flaw (CVSS 9.4) in the CloudCharge cloudcharge.se charging backend. Its OCPP WebSocket endpoint lets a client pose as a charger without credentials. CISA says the vendor did not respond, so no fix is confirmed. Reduce exposure and contact CloudCharge.
What's affected
CISA advisory ICSA-26-057-03 lists CloudCharge cloudcharge.se as affected in all versions. The weakness is CWE-306 (missing authentication for a critical function). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L.
The record describes WebSocket endpoints without proper authentication. An unauthenticated client can connect with a known or discovered charging station identifier and then send or receive OCPP commands as if it were that charger. OCPP is the Open Charge Point Protocol that chargers use to talk to their backend.
The same advisory covers other CloudCharge issues, such as missing rate limits on authentication, insufficient session expiration and insufficiently protected credentials. CISA states that CloudCharge did not respond to its request for coordination, so I could not confirm any fixed version. CISA also says it has no report of public exploitation specifically targeting these vulnerabilities. The record does not mark the issue as exploited, and it is not in the CISA Known Exploited Vulnerabilities catalog.
How to check if you're exposed
If you operate chargers that connect to a CloudCharge backend, or you are an operator who uses the platform, ask your provider in writing whether the OCPP endpoint requires authentication and whether they have a fix.
On your own side, review what you can see:
- Which charger identifiers are registered, and whether any are guessable or sequential.
- Backend logs for connections from unexpected addresses or for identifiers that you did not provision.
- Charger configuration for the security profile in use. OCPP defines profiles that add passwords and TLS, and a charger set to the weakest profile gives the backend little to check.
What to do now
- Contact CloudCharge through the support page that CISA gives, and ask for the status of a fix and for a timeline.
- Ask whether your chargers can use a stronger OCPP security profile, with TLS and per charger credentials, and turn it on where supported.
- Use identifiers that are not guessable, and rotate any that may have leaked.
- Follow the CISA recommended practices: keep control networks off the internet, put them behind firewalls and use a VPN for remote access.
- Monitor backend sessions and alert on a second connection claiming the same charger identifier.
Why it matters
Many control system protocols were designed for closed networks, and authentication was added later or not at all. When a service on the internet trusts a station identifier as if it were a secret, anyone who learns the identifier can speak as that station. The charging backend then believes data it should not.
For an operator the effect is not only a data problem. Wrong meter readings, wrong status messages and commands sent to real hardware affect billing and availability, and the advisory says an attack could cause large scale disruption. Missing authentication is a design gap, so the fix has to come from the vendor. Until it does, limit who can reach the endpoint and watch it.
Quick check
Does the vendor have a patch?
CISA says CloudCharge did not respond to its coordination request, so I could not confirm one. Ask the vendor directly and check the CISA advisory for updates.
Sources
- CISA advisory ICSA-26-057-03: CloudCharge cloudcharge.se
- CloudCharge support contact page
- NVD record for CVE-2026-20781
Last reviewed: 19 October 2026.
