Critical EV Charging Flaws Expose ePower epower.ie to Remote Hijacking

As the world accelerates toward green energy adoption, the cybersecurity maturity of Electric Vehicle (EV) infrastructure is being tested in real-time. A recent advisory from CISA has brought to light a set of concerning vulnerabilities in ePower epower.ie charging station software. These flaws aren't just software bugs; they represent a fundamental failure in authentication logic that could allow attackers to seize administrative control of charging stations or disrupt power delivery services entirely.

With a CVSS score of 9.4 (Critical), the most severe of these vulnerabilities highlights a growing trend in Operational Technology (OT) threats: the convergence of IT web protocols with physical infrastructure, often lacking the security layers standard in traditional web applications.

The Vulnerability Deep Dive

The core issue lies in the implementation of the Open Charge Point Protocol (OCPP), typically transported over WebSockets. ePower's implementation suffers from multiple design flaws that effectively strip away identity verification.

1. Missing Authentication (CVE-2026-22552)

The most critical flaw is the complete lack of authentication on WebSocket endpoints. In a secure OCPP implementation, the charging station (the client) authenticates to the central system (the server) using credentials. In ePower's case, an attacker needs only the Charging Station Identifier (Station ID), which is often predictably formatted or publicly exposed.

The Attack Vector:

1. An attacker enumerates or discovers a valid Station ID.
2. The attacker initiates a WebSocket connection to the backend server masquerading as the physical charger.
3. Since the server accepts the connection without verifying credentials (CWE-306), the attacker gains the ability to send and receive OCPP commands.

This allows for privilege escalation and unauthorized control—effectively letting a remote attacker turn chargers on or off, manipulate billing data, or corrupt network telemetry.

2. Session Hijacking and Shadowing (CVE-2026-24912)

The vulnerability regarding insufficient session expiration (CWE-613) enables "session shadowing." The system allows multiple active connections using the same Session Identifier. An attacker can initiate a connection using a legitimate station's ID. When the actual station comes online and tries to connect, or sends data, the attacker's connection can "shadow" or displace the legitimate traffic. The attacker effectively becomes the "man-in-the-middle," receiving backend commands intended for the hardware.

3. Excessive Attempts and Credential Exposure (CVE-2026-27778 & CVE-2026-27770)

To make matters worse, the API lacks rate limiting (CWE-307), facilitating brute-force attacks or Denial-of-Service (DoS) conditions by flooding the backend with connection requests. Furthermore, the Station IDs intended for authentication are often publicly accessible via web-based mapping platforms (CWE-522), providing attackers with the target list needed to exploit CVE-2026-22552.

Detection and Threat Hunting

Detecting these vulnerabilities requires monitoring network traffic specifically for OCPP anomalies over WebSockets. Security teams should look for multiple IP addresses connecting with the same Station ID or connections from unexpected geographic locations.

KQL Query for Sentinel/Defender

Use this query to detect potential unauthorized connection attempts or session hijacking involving OCPP endpoints:

DeviceNetworkEvents
| where RemotePort in (80, 443, 8000, 9000) // Common WebSocket/OCPP ports
| extend ApplicationProtocol = tostring(Columns["ApplicationProtocol"])
| where ApplicationProtocol =~ "ws" or ApplicationProtocol =~ "wss" or AdditionalFields has "OCPP"
| summarize ConnectionCount = count(), DistinctIPs = dcount(SourceIP) by DestinationIP, InitiatingProcessFileName
// Look for multiple Source IPs connecting to a single Backend Destination (Potential Hijacking)
| where DistinctIPs > 1
| project TimeGenerated, DestinationIP, DistinctIPs, ConnectionCount, InitiatingProcessFileName
| order by ConnectionCount desc

Python Script for OCPP Endpoint Validation

This script checks if an OCPP endpoint requires authentication or accepts connections without proper handshake validation (useful for internal auditing):

import asyncio
import websockets
import 

async def check_ocpp_auth(uri, station_id):
    try:
        # Attempt to connect using a generic OCPP 1.6 JSON request
        connect_payload = .dumps([2, "1", "BootNotification", {"chargePointModel": "Test", "chargePointVendor": "Attacker"}])
        
        print(f"[*] Attempting connection to {uri} as Station ID: {station_id}")
        async with websockets.connect(uri, extra_headers={"Sec-WebSocket-Protocol": "ocpp1.6"}) as websocket:
            await websocket.send(connect_payload)
            response = await websocket.recv()
            print(f"[+] Response Received: {response}")
            print("[!] WARNING: Connection accepted. Authentication may be missing.")
            return True
            
    except websockets.exceptions.InvalidStatusCode as e:
        print(f"[-] Connection Rejected ({e.status_code}). This may indicate proper auth/firewalling.")
        return False
    except Exception as e:
        print(f"[?] Error: {e}")
        return False

# Example usage
# asyncio.run(check_ocpp_auth("ws://target-ev-charger-backend.com/ocpp", "ALICE-001"))

Bash: Network Segmentation Verification

Ensure charging stations are not directly accessible from the open internet:

#!/bin/bash
# Scan a subnet for open WebSocket ports commonly used by EV chargers
TARGET_SUBNET="192.168.1.0/24"
PORTS="80 443 8080 8888"

echo "[*] Scanning $TARGET_SUBNET for open WebSocket ports..."
for port in $PORTS; do
  nmap -p $port --open -T4 $TARGET_SUBNET | grep -B 4 "open"
done

echo "[!] Review results: Any charging station management ports should not be 'open' to the Internet."

Mitigation and Remediation

The situation with ePower is complicated by the fact that, according to CISA, the vendor did not respond to coordination requests. Therefore, immediate mitigation relies heavily on network architecture and strict access controls.

1. Network Isolation (Critical): Move all charging station management systems (CSMS) and the chargers themselves behind a firewall. Ensure the OCPP WebSocket ports (often 80/443 or custom ports) are not accessible from the public internet. Force all management traffic through a VPN or a dedicated, screened subnet.

2. Enforce Inbound Filtering: Configure firewalls to only allow inbound connections from known, whitelisted IP addresses of the physical charging stations. Block any other IP attempting to initiate an OCPP session.

3. Implement Application Gateways: Place a Web Application Firewall (WAF) or an API Gateway in front of the charging station backend. Configure it to enforce rate limiting (mitigating CVE-2026-27778) and to inspect WebSocket handshakes for anomalies.

4. Audit Public Exposure: Immediate search for any maps or public documentation that lists your organization's charging station IDs. Remove these identifiers or ensure they cannot be used as an authentication token.

Executive Takeaways

The rapid deployment of smart infrastructure often outpaces security implementation. The ePower vulnerabilities demonstrate a classic "Securing the Perimeter" failure. By treating the Charging Station ID as a secret (when it is publicly exposed) and failing to authenticate WebSocket connections, the system effectively leaves the front door unlocked.

Organizations deploying EV infrastructure must demand that vendors implement mutual TLS (mTLS) or strong token-based authentication for OCPP connections. Until then, network segmentation is your only viable defense.

Related Resources

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