CVE-2026-25851: Critical Authentication Bypass in Chargemap OCPP Backend

CVE-2026-25851 identifies a critical security flaw in the backend infrastructure of chargemap.com, specifically within the endpoints handling the Open Charge Point Protocol (OCPP). The vulnerability is classified as Missing Authentication for Critical Function (CWE-306). Ideally, OCPP implementations require charging stations (Charge Points) to authenticate using a unique token, password (Basic Auth), or client certificate (mTLS) during the WebSocket handshake.

In the affected Chargemap implementation, the backend fails to verify the identity of the connecting client beyond the Station ID provided in the connection URL. This architectural oversight allows any entity with knowledge of a valid Station ID to establish a full-duplex WebSocket connection with the Central System. Once connected, the attacker is effectively treated as the physical charging station, gaining the ability to send status updates and receive remote commands.

The impact is severe because the Station IDs—intended to be public identifiers for users to locate chargers—are effectively used as the sole authentication factor. This conflates identity (who you are) with authentication (proving who you are), removing the security barrier between public knowledge and privileged access.

The root cause lies in the implementation of the WebSocket handshake for OCPP. The OCPP specification (versions 1.6 and 2.0.1) defines security profiles. Security Profile 1 allows for HTTP Basic Authentication, while Profiles 2 and 3 mandate TLS and client certificates. The Chargemap backend appears to accept connections without enforcing these authentication layers.

Vulnerable Handshake Logic: When a standard WebSocket client initiates a connection, the request looks like this:

GET /ocpp/STATION-12345 HTTP/1.1
Host: backend.chargemap.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Protocol: ocpp1.6

The server logic validates only the existence of STATION-12345. If the ID exists in the database, the server responds with 101 Switching Protocols, establishing the session. No Authorization header is requested or verified.

Secure Implementation Requirement: A secure implementation must challenge the client. For Security Profile 1 (or 2), the request must include credentials:

Authorization: Basic <Base64(StationID:Password)>

The absence of this check means the security of the entire charging network relies on the secrecy of the Station ID. However, as noted in the related CVE-2026-20791, these IDs are publicly exposed via mapping interfaces, rendering the secrecy assumption invalid.

The exploitation of this vulnerability is trivial and requires low technical skill, contributing to its critical severity. The attack chain follows a standard logic flaw exploitation path.

1. Reconnaissance

The attacker first obtains a target Station ID. Due to CVE-2026-20791, these IDs are available on public maps or the Chargemap application itself. No scanning or brute-forcing is required if the ID format is known or scraped.

2. Connection Establishment

The attacker uses a WebSocket client (e.g., wscat or a custom Python script) to connect to the backend.

# Example connection attempt
wscat -c wss://backend.chargemap.com/ocpp/CP_12345 -s ocpp1.6

3. Session Shadowing

Upon successful connection, the backend may behave in two ways regarding the legitimate station's existing connection. Per CVE-2026-25711, the system allows multiple connections or allows the new connection to override the old one (Ghost Connection/Shadowing). The attacker creates a 'BootNotification' to register their rogue client.

[
    2,
    "msg_id_001",
    "BootNotification",
    {
        "chargePointVendor": "Attacker",
        "chargePointModel": "VirtualStation"
    }
]

4. Operational Manipulation

Once the session is active, the attacker can:

• Stop Charging: Send StatusNotification indicating a fault or simply accept a RemoteStopTransaction command.
• Billing Fraud: Send falsified MeterValues to inflate or deflate energy consumption records.
• Denial of Service: Keep the connection open to prevent the legitimate hardware from reporting its status.

The convergence of missing authentication and public identifiers creates a high-impact scenario for Charge Point Operators (CPOs) utilizing the Chargemap backend.

• Integrity (High): Attackers can inject false data into the system. This corrupts historical usage logs, billing information, and station availability status. Operators cannot trust the data reported by their infrastructure.
• Confidentiality (High): By establishing a session, an attacker can receive messages intended for the station. This may include configuration keys, user authorization tokens (idTags) used by drivers to start charging, or firmware update URLs.
• Availability (Low/Medium): While the attacker cannot physically damage the hardware via this specific vector, they can disrupt service. By 'shadowing' the session, they prevent the real charger from communicating, potentially leaving users unable to start a charge (if the charger requires backend authorization).

CVSS v3.1 Vector Analysis:

• AV:N/AC:L/PR:N: Network accessible, low complexity, no privileges required. This is the most dangerous combination for a remote API.
• S:U: The scope is unchanged (affects the backend/station relationship directly).
• C:H/I:H: Total compromise of the data stream between station and server.

> [!WARNING] > No Patch Available: As of the publication date, the vendor (Chargemap) has not responded to CISA coordination requests or released a patch.

Mitigation Strategies

Since the vulnerability resides on the vendor's cloud backend, end-users (EV drivers) have no mitigation options. Charge Point Operators (CPOs) who rely on Chargemap for backend management should take the following steps:

1. Network Isolation: If the charging stations support it, restrict outbound network traffic to a VPN tunnel rather than the public internet. This does not fix the backend flaw but may obscure the station's public footprint if the ID was being scraped from network traffic.
2. ID Obfuscation: Ensure physical labels on charging stations do not reveal the internal Station ID used for OCPP connections. While IDs may still be scraped from the map, removing physical indicators adds a layer of friction.
3. Vendor Pressure: Customers should contact Chargemap support immediately to demand the implementation of OCPP Security Profile 2 (TLS with Basic Auth) or Profile 3 (TLS with Client Certificates). The reliance on Station ID alone is non-compliant with modern security standards.