Critical CloudCharge Flaws Expose Global EV Charging Infrastructure to Hijacking and DoS

The rapid expansion of Electric Vehicle (EV) infrastructure is transforming the transportation sector, but it is also creating a lucrative attack surface for cybercriminals. A recent advisory from CISA has laid bare significant security deficiencies in CloudCharge’s charging station management platform. With a CVSS score of 9.4, these vulnerabilities represent a tangible threat to the Energy and Transportation critical infrastructure sectors, allowing attackers to impersonate charging stations, hijack user sessions, and disrupt power distribution networks.

The Threat Landscape: Unplugged and Unprotected

At the core of this advisory is a failure to implement fundamental security controls in the Open Charge Point Protocol (OCPP) implementation over WebSockets. The vulnerabilities, tracked as CVE-2026-20781, CVE-2026-25114, CVE-2026-27652, and CVE-2026-20733, affect all versions of the CloudCharge cloudcharge.se platform.

What makes this situation particularly volatile is the vendor's silence. According to CISA, CloudCharge did not respond to coordination requests. For Security Operations Centers (SOCs) managing OT environments, this silence necessitates an immediate shift to "assume breach" mentality and the implementation of aggressive compensating controls.

Technical Analysis: Breaking the Charge

The vulnerabilities in question are not subtle implementation bugs; they are architectural failures that undermine the trust model of the charging infrastructure.

1. Authentication Bypass (CVE-2026-20781)

This is the most severe flaw (CVSS 9.4). The WebSocket endpoints lack proper authentication. In a properly secured OCPP implementation, the charging station authenticates to the backend using a certificate or token. Here, an attacker can simply connect to the WebSocket endpoint using a discovered or known Charging Station ID. This allows an attacker to:

• Impersonate Station: Tell the backend the charger is online/offline at will.
• Manipulate Data: Send fake telemetry or billing data.
• Privilege Escalation: Gain unauthorized control over the management interface.

2. Session Hijacking and Race Conditions (CVE-2026-27652)

The backend allows multiple WebSocket connections to bind to the same Charging Station ID simultaneously. The implementation favors the "most recent" connection, effectively letting an attacker "shadow" a legitimate charger. Once the attacker connects, they steal the session, receive the commands intended for the physical hardware, and can cause the legitimate hardware to disconnect or malfunction.

3. Denial of Service (CVE-2026-25114)

The lack of rate limiting on authentication requests allows attackers to flood the WebSocket API. Furthermore, by exploiting the session hijacking flaw, they can disconnect thousands of chargers simultaneously, causing a large-scale denial of service.

4. Exposed Credentials (CVE-2026-20733)

The attack surface is widened by the fact that Charging Station IDs—often used as the primary authentication mechanism—are publicly accessible via web-based mapping platforms, essentially providing a target list for attackers.

Detection and Threat Hunting

Given the vendor's lack of a patch, network visibility is your only defense. SOC teams should monitor for anomalies in WebSocket traffic and OCPP protocol headers.

KQL Queries for Sentinel/Defender

Hunt for Session Hijacking (Multiple IPs for Single Station ID): This query looks for multiple distinct source IPs connecting to the same destination endpoint (simulating a station ID) within a short window.

let timeframe = 1h;
DeviceNetworkEvents
| where Timestamp > ago(timeframe)
// Filter for WebSocket traffic or known CloudCharge domains
| where RemoteUrl contains "cloudcharge" or DestinationPort in (80, 443, 8000, 8080) 
| extend StationID = extract(@"stationID=([^&]+)", 1, RequestURL) 
// If URL params aren't clear, use DestinationURL or specific headers if available
| summarize ConnectionCount = count(), UniqueIPs = dcount(SourceIP), make_set(SourceIP) by bin(Timestamp, 5m), DestinationUrl, StationID
| where UniqueIPs > 1
| project Timestamp, DestinationUrl, StationID, UniqueIPs, IPList = set_SourceIP
| order by Timestamp desc


**Hunt for Potential Brute Force or DoS (CVE-2026-25114):**
DeviceNetworkEvents
| where Timestamp > ago(1h)
| where RemoteUrl contains "cloudcharge" 
| where ActionType == "ConnectionAccepted" or ActionType == "ConnectionAttempt"
| summarize Requests = count() by SourceIp, bin(Timestamp, 1m)
| where Requests > 50 // Threshold for abnormal connection attempts
| project Timestamp, SourceIp, Requests
| order by Requests desc

Bash Script for Log Analysis

If you have proxy logs or firewall exports, you can use this snippet to quickly identify potential scanning activity targeting exposed infrastructure.

#!/bin/bash
# Analyze nginx or proxy logs for WebSocket Upgrade requests targeting suspicious endpoints
LOG_FILE="/var/log/nginx/access.log"
OUTPUT_FILE="cloudcharge_scan_detected.txt"

# Check for WebSocket upgrades and HTTP 1.1
# Look for rapid connections from single IPs
echo "Checking for WebSocket connection anomalies..."

grep "Upgrade: websocket" "$LOG_FILE" | \
awk '{print $1}' | \
sort | \
uniq -c | \
sort -nr | \
awk '$1 > 100 {print "High Frequency IP: "$2" - Connections: "$1}' > "$OUTPUT_FILE"

if [ -s "$OUTPUT_FILE" ]; then
  echo "[ALERT] Potential scanning or DoS activity detected. See $OUTPUT_FILE"
  cat "$OUTPUT_FILE"
else
  echo "No immediate high-frequency anomalies detected in log file."
fi

Python Script for Session Validation

While we cannot fix the backend, we can script a check to see if a station ID is currently being associated with multiple IPs (a symptom of active hijacking).

import socket
import re

# WARNING: Only run this against infrastructure you own or have explicit authorization to test.
def check_websocket_session(target_host, station_id):
    """
    Simulates a connection check to see if a Station ID responds.
    Note: This is a conceptual check for logic validation, not a full exploit.
    """
    try:
        # Normal socket connection to verify basic reachability
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.settimeout(5)
        # Assuming standard WS port (often 80/443 or 8080)
        result = sock.connect_ex((target_host, 80)) 
        sock.close()
        
        if result == 0:
            return f"Host {target_host} is reachable. Review backend logs for session ID {station_id} for duplicates."
        else:
            return f"Host {target_host} unreachable."
    except Exception as e:
        return f"Error checking socket: {e}"

# Example Usage
# print(check_websocket_session("192.168.1.50", "CHARGER_001"))

Mitigation Strategies

Without a vendor patch, organizations relying on CloudCharge must implement network-level segmentation to survive.

1. Network Isolation (Critical): Ensure charging station networks are strictly segmented from the business network and the public internet. Control system networks should be placed behind firewalls with deep packet inspection (DPI) capabilities.

2. VPN Enforcement: If remote access is required for maintenance, enforce VPN usage. However, remember that VPNs are only as secure as the devices connecting to them. Ensure Multi-Factor Authentication (MFA) is enforced on all VPN access points.

3. Ingress/Egress Filtering: Block direct WebSocket connections from the internet to the CloudCharge backend. Restrict traffic to known, static IP addresses of physical charging stations.

4. Monitor for OSINT: Actively monitor web mapping platforms to see if your organization's charging station IDs have been leaked. If found, request removal immediately and rotate the IDs if the platform supports it (though this may be difficult without vendor support).

Conclusion

The CloudCharge vulnerabilities highlight the immaturity of cybersecurity in the booming EV market. While we wait for vendor action, the responsibility falls entirely on the infrastructure owners. By implementing aggressive network segmentation and monitoring for the TTPs outlined above, you can prevent a critical charging station from becoming a critical security liability.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub