On 26 February 2026 CISA released advisory ICSA-26-057-04 on EV2GO, a UK based charging platform at ev2go.io. It lists four vulnerabilities and an overall CVSS v3 score of 9.4. The headline issue, CVE-2026-24731, is that the OCPP WebSocket endpoint can be reached without authentication using a known or discovered charging station ID, so an attacker can impersonate a charger.
Safeguard does not operate chargers. This post uses the advisory to explain what a backend for physical equipment must get right.
What's affected
All versions of ev2go.io are listed. The advisory records these issues:
| CVE | CVSS v3.1 | Weakness |
|---|---|---|
| CVE-2026-24731 | 9.4 | Missing authentication on the OCPP WebSocket endpoint (CWE-306) |
| CVE-2026-25945 | 7.5 | No limit on authentication requests, enabling brute force or denial of service (CWE-307) |
| CVE-2026-20895 | 7.3 | Multiple endpoints can use the same session identifier, enabling hijacking (CWE-613) |
| CVE-2026-22890 | 6.5 | Station authentication identifiers are publicly accessible through web mapping platforms (CWE-522) |
The advisory says EV2GO did not respond to CISA's coordination requests, so no vendor fix is listed. CISA has not received reports of known public exploitation. The fourth row matters: the identifier needed for the first attack can be found on public maps.
How to check if you're exposed
If you run or buy from a charging network, ask the operator four questions.
- Does each charger authenticate to the backend with something other than its identifier?
- Are authentication attempts rate limited?
- Can two sessions share an identifier?
- Where else are station identifiers published?
If you build a backend, test for the same four.
What to do now
- Follow CISA's general advice: minimize network exposure, put control system devices behind firewalls and isolate them from business networks.
- For remote access use an updated VPN, keeping in mind CISA's note that a VPN is only as secure as the devices connected to it.
- Ask your operator for a written answer on the four questions above, and a contact for security reports.
- Treat station identifiers as public, never as secrets.
How this could have been avoided
Authentication that does not rest on a guessable or published identifier would have closed the first and fourth issues together. Request limits address the third. Session identifiers bound to one client address the second. A staffed security contact and a response process matter too, since the advisory records no vendor reply to CISA.
Why it matters
A related CISA advisory, ICSA-25-303-01 (released 30 October 2025, revised 17 March 2026), covers CVE-2025-12357 in ISO 15118-2, where spoofed SLAC measurements can place an attacker between a vehicle and a charger. It rates 6.3 and is not remotely exploitable. ISO recommends TLS with certificate chaining, as specified in ISO 15118-20, where TLS is required rather than recommended.
Together they show two layers: the vehicle to charger link and the charger to cloud link. Both need authentication that holds up when the identifier is known.
Try it yourself
Pick one service your equipment talks to. Write the incident timeline you would want if its endpoint were impersonated, then compare with the demo.
Click through it at your own pace, or open it full screen.
Quick check
What does an attacker need to exploit CVE-2026-24731?
A known or discovered charging station ID. No authentication is required on the OCPP WebSocket endpoint.
