CVE-2026-29796: WebSocket OCPP Auth Bypass Vulnerability

CVE-2026-29796 Overview

CVE-2026-29796 is a critical authentication bypass vulnerability affecting OCPP (Open Charge Point Protocol) WebSocket endpoints. The vulnerability allows unauthenticated attackers to connect to WebSocket endpoints using known or discovered charging station identifiers, enabling unauthorized station impersonation and manipulation of data transmitted to backend systems.

This vulnerability poses a significant threat to electric vehicle charging infrastructure, as attackers can issue or receive OCPP commands while masquerading as legitimate chargers. The lack of proper authentication mechanisms creates opportunities for privilege escalation, unauthorized control of charging stations, and corruption of charging network data.

Critical Impact

Unauthenticated remote attackers can impersonate legitimate charging stations, issue arbitrary OCPP commands, and manipulate backend data, potentially disrupting charging infrastructure operations and compromising billing integrity.

Affected Products

• OCPP WebSocket endpoint implementations lacking authentication
• Electric vehicle charging station management systems
• Backend charging network infrastructure communicating via OCPP

Discovery Timeline

• 2026-03-20 - CVE CVE-2026-29796 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-29796

Vulnerability Analysis

This vulnerability stems from CWE-306: Missing Authentication for Critical Function. The OCPP WebSocket endpoints fail to implement proper authentication mechanisms, allowing any network-accessible attacker to establish connections without credentials.

The attack is network-based and requires no user interaction or prior privileges. An attacker with network access to the OCPP WebSocket endpoint can connect using a known or enumerated charging station identifier. Once connected, the attacker operates with the same privileges as a legitimate charging station, enabling them to send and receive OCPP protocol messages.

The impact is severe across confidentiality and integrity dimensions. Attackers can access sensitive charging session data, manipulate reported energy consumption, disrupt charging operations, and potentially cause financial damage through fraudulent transactions. The availability impact is limited but still present, as attackers could interfere with legitimate charging operations.

Root Cause

The root cause is the complete absence of authentication controls on the OCPP WebSocket endpoint. The system accepts connections from any client that presents a valid charging station identifier without verifying the client's identity or authorization to act on behalf of that station. This design flaw violates fundamental security principles by trusting client-provided identifiers without verification.

Charging station identifiers may be predictable, enumerable, or discoverable through network reconnaissance, making them insufficient as the sole means of access control. The protocol implementation lacks:

• Client certificate validation
• API key or token-based authentication
• Challenge-response mechanisms
• IP allowlisting or network segmentation controls

Attack Vector

The attack is executed over the network against exposed OCPP WebSocket endpoints. An attacker first identifies or discovers valid charging station identifiers through enumeration, network sniffing, or OSINT research on deployed charging infrastructure. The attacker then establishes a WebSocket connection to the target endpoint, presenting the stolen or discovered station identifier.

Once connected, the attacker can send malicious OCPP commands such as BootNotification, StartTransaction, StopTransaction, MeterValues, and StatusNotification messages. These commands allow the attacker to report false energy consumption data, terminate legitimate charging sessions, or manipulate billing records. The attack requires no special tools beyond standard WebSocket clients and knowledge of the OCPP protocol specification.

Detection Methods for CVE-2026-29796

Indicators of Compromise

• Multiple concurrent WebSocket connections from different IP addresses using the same charging station identifier
• Connections to OCPP endpoints originating from unexpected geographic locations or IP ranges
• Anomalous OCPP command sequences inconsistent with normal charging station behavior
• Discrepancies between reported charging data and physical energy meter readings

Detection Strategies

• Implement connection logging for all OCPP WebSocket endpoints with source IP tracking
• Monitor for duplicate station identifier usage across multiple active sessions
• Deploy network intrusion detection rules for anomalous OCPP protocol patterns
• Correlate backend charging data with physical station telemetry to detect manipulation

Monitoring Recommendations

• Enable detailed audit logging for all OCPP message exchanges
• Establish baseline connection patterns for legitimate charging stations and alert on deviations
• Monitor for rapid connection/disconnection cycles that may indicate enumeration attempts
• Implement real-time alerting for OCPP commands from unregistered or unexpected source IPs

How to Mitigate CVE-2026-29796

Immediate Actions Required

• Implement network segmentation to restrict OCPP WebSocket endpoint access to authorized networks only
• Deploy IP allowlisting to limit connections to known charging station IP ranges
• Enable TLS client certificate authentication for all WebSocket connections
• Review and audit all active charging station registrations for unauthorized entries

Patch Information

Organizations should consult the CISA ICS Advisory #26-078-08 for specific vendor patch information and remediation guidance. The GitHub CSAF Document contains additional technical details and affected version information.

Contact your OCPP implementation vendor for available security updates that implement proper authentication mechanisms.

Workarounds

• Implement a VPN or private network for all charging station communications
• Deploy a reverse proxy with authentication in front of OCPP WebSocket endpoints
• Use firewall rules to restrict access to OCPP endpoints from the public internet
• Consider implementing application-layer authentication tokens until vendor patches are available

# Example: Restrict OCPP WebSocket access using iptables
# Allow only known charging station subnet
iptables -A INPUT -p tcp --dport 9000 -s 10.100.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 9000 -j DROP

# Enable connection logging for audit purposes
iptables -A INPUT -p tcp --dport 9000 -j LOG --log-prefix "OCPP-CONNECTION: "