EVMAPA’s charging‑station software was publicly flagged in a coordinated CISA advisory that assigns three CVE identifiers — CVE‑2025‑54816, CVE‑2025‑53968 and CVE‑2025‑55705 — and classifies the cluster as a high‑to‑critical risk to EV charging infrastructure because successful exploitation can result in degraded service, denial‑of‑service, or unauthorized remote command execution that could spoof or manipulate charger status. The vendor’s coordination notes and the advisory text describe missing authentication on a WebSocket OCPP endpoint, unlimited authentication attempts (allowing brute‑force or DoS), and insufficient session expiration / simultaneous‑session handling for charging station IDs. These weaknesses affect EVMAPA deployments in at least two countries named in the advisory and have already prompted vendor fixes and operational guidance for operators. rview
EVMAPA is a charging‑infrastructure vendor whose stack interfaces with charge points over the Open Charge Point Protocol (OCPP) and transports OCPP messages commonly via WebSockets (WSS). The CISA advisory places this disclosure within the broader class of industrial control system (ICS) / critical‑infrastructure warnings: missing authentication, absent rate limiting, and poor session management are recurring root causes that produce outsized operational risk when present on network‑reachable management interfaces. CISA‑style mitigation recommendations — minimize Internet exposure, segment control networks, and use secure remote access mechanisms such as updated VPNs and hardened jump hosts — are reiterated across ICS advisories and are the canonical first‑line defenses for missing‑auth and session‑management faults. The advisory assigns high CVSS scores to these findings (one item is scored as CVSS v3.1 9.4, labeled CRITICAL; the two others carry CVSS v3.1 base scores in the mid‑7 range). Those severity labels reflect that the functions are network‑accessible, require no user interaction, and impact confidentiality/integrity/availability in the charging‑station control plane.
The three vulnerabilities — technical summary and vendor status
CVE‑2025‑54816 — Missing authentication on WebSocket (OCPP) endpoint
- The advisory states a WebSocket endpoint used for OCPP communication does not require authentication, allowing any reachable actor to open a connection and issue or observe control messages.
- Technical risk: OCPP over WebSocket is the protocol path for remote status, supply negotiation, authorization key changes, and command delivery. When a charging station accepts unauthenticated WebSocket connections, an attacker can escalate privileges, manipulate session state, or inject commands that the back‑end treats as legitimate.
- Vendor remediation: EVMAPA reports that some of their stations do not permit changes to the authorization key via OCPP and that operators may connect stations over WSS or vendor VPN. EVMAPA plans to implement BASIC authorization control on OCPP 2.x and newer stations. This is a partial remedy: BASIC auth over WSS can be effective if credentials are unique, protected, and enforced by the server, but the fix must be deployed universal
CVE‑2025‑53968 — No limits on authentication attempts (brute‑force / DoS)
- The advisory reports the authentication endpoint accepts unlimited authentication attempts with no lockout or throttling.
- Technical risk: Attackers can brute‑force credentials (especially when weak/default credentials are present), or they can flood the authentication interface to cause denial‑of‑service. Even if credential guessing fails, an unlimited retry policy creates an easy vector for automated disruption.
- Vendor remediation: No public vendor statement was provided in the advisory for this specific finding. The advisory recommends contacting EVMAPA for details; operators should assume until proven otherwise that rate limiting and lockout controls are not universally implemented. — Insufficient session expiration / simultaneous session reuse of charging station ID
- The advisory explains the system allowed multiple simultaneous backend connections using the same charge‑point ID (CBID), enabling session reuse or concurrent sessions that can lead to inconsistent state, data races, and session hijacking.
- Technical risk: OCPP and backend systems rely on a one‑to‑one association between a charge point and its active session for command ordering and state consistency. Allowing concurrent sessions with the same ID can be abused to replay or suppress transactions and to overwrite legitimate operator commands.
- Vendor remediation: EVMAPA told the coordinating authority they resolved this issue and now disallow simultaneous connections for the same CBID, which closes the immediate abuse path if the fix is correctly deployed and tested across all affected stations.
What’s verdent confirmation and gaps
- The advisory text supplied to operators is consistent with multiple CISA ICS advisories that emphasize missing authentication, credential handling, and session management as recurring high‑impact problems. This pattern and the recommended mitigations match prior public advisories and operational guidance.
- The vendor’s claim of a resolved session 025‑55705 is a concrete remediation claim; operators should validate by confirming that their charging‑station firmware and back‑end versions match the vendor’s fixed release and by performing end‑to‑end connection tests that attempt simultaneous connections with the same CBID to confirm the fix. The advisory’s statement that EVMAPA “informed CISA they have resolved this issue” is recorded in the coordinating materials, but independent confirmation requires confirming installed firmware/outage windows on the operator’s stations.
- The claim that “no known public exploitation was reported to publication” is common language in coordinated disclosures, but operators should treat “no known exploitation” as a temporary status — absence of reported exploitation is not proof of safety, particularly when the vulnerabilities are straightforward to weaponize. When primary vendor statements or CISA pages are not reachable from within an operator’s network zone, validate via vendor PSIRT notices and CVE/NVD entries where available.
Caveat on verification: direct retrieval of the canonical CISA advisory page may tworks or gated; when that happens, operators must obtain the advisory from vendor PSIRT channels, trusted vulnerability feeds, or their national CERT. CISA’s vulnerability bulletins and mitigation guidance are also available as canonical guidance and should be consulted for cross‑checks.
Risk analysis — why these findings matter operationally
- Charging infrastructure is an operational control plane: manipulation of charger status, session states, and authorization can enable incorrect billing, fraudulent charge sessions, denial of service of chargers, or mass misreporting of availability that undermines fleet operations.
- Missing authentication on a persistent transport (WebSocket) is a high‑leverage flaw: attackers can subscribe to telemetry streams to harvest credentials or keys, inject control frames to override operator commands, or issue OCPP firmware/authorization commands depending on the station’s implementation.
- Unlimited authentication attempts present two simultaneous risks: credential compromise (if weak passwords are in use) and service disruption by flooding. Both are attractive to automated attacker tooling and botnets that scan for exposed management endpoints.
- Concurrent sessions with the same station ID allow race conditions and state machine confusion that may be more than just an integrity problem — they enable a remote attacker to create confusion at scale (for example, turning chargers on/off unpredictably during peak demand), with potential safety or grid‑stability impacts where charging is tightly integrated with energy management.
These are not theoretical: prior ICS advisories show how missing authentication and poor session controls lead quickly to large‑scale exploitation once PoC code circulates. The mitigation principles — segment, isolate, patch, and apply principle‑of‑least‑privilege access — are the same across those incidents.
Practical actions for operatorlist
The following steps are written for operators, charge‑point managers, and Windows‑centric engineering teams that host OCPP back ends, management consoles, or VPN gateways.
- Inventory and exposure assessment (Immediate)
- Identify every EVMAPA‑managed charging station and record firmware version, OCPP version (1.6, 2.x), connection transport (WSS vs VPN), and whether the station accepts remote authorization changes.
- Determine whether any management or OCPP WebSocket endpoints are directly reachable from the Internet, DMZ, or business networks.
- Validate vendor fixes and patches (24–72 hours)
- Confirm EVMAPA fixed releases for your deployed models addressing CVE‑2025‑55705 and verify whether BASIC auth implementation for OCPP 2.x is available and mandatory.
- If a patch is available, schedule prioritized staged rollout: test on a pilot subset, confirm behavioral changes (session concurrency disabled; BASIC auth negotiation enforced), then expand.
- Apply network compensations if patching is delayed
- Block public Internet access to OCPP management ports with perimeter firewall rules.
- Place charging stations and back‑end systems on a dedicated OT VLAN with ACLs that permit only known jump hosts and management IPs to connect.
- Require multi‑factor authentication on any remote access points to management consoles or VPN entry points.
- Harden authentication and rate limiting
- Enforce unique, strong credentials for station‑to‑backend connections. Replace any default or shared keys.
- Implement server‑side rate limiting and account lockout for authentication endpoints (e.g., 5 failed attempts → time‑based lockout or exponential backoff).
- Use WSS (TLS) with properly validated server certs; disable plaintext ws:// endpoints.
- Session management & telemetry checks
- Confirm that the back‑end rejects simultaneous sessions for the same CBID; add monitoring to detect duplicate session‑ID use.
- Log WebSocket open/close events, source IPs, and connection durations; alert on suspicious patterns (many short-lived connections, multiple concurrent connections from distinct IPs using same CBID).
- Monitoring, detection, and response
- Create SIEM rules for:
- Repeated failed authentication attempts to OCPP endpoints.
- Multiple concurrent WebSocket connections using identical charger IDs.
- Unexpected authorization‑key changes or OCPP Autorize/StartTransaction sequences initiated from unknown IPs.
- Preserve logs and packet captures if suspicious activity is observed; follow ICS incident response playbooks for containment.
- Test and audit
- Perform a red‑team / penetration test focused on OCPP endpoints, WebSocket handshake correctness, and session enforcement.
- Validate that BASIC auth (or stronger) is negotiated and that stations refuse plain or unauthenticated connections.
- Operational governance and supplier engagement
- Require vendors to publish PSIRT advisories, fixed version numbers, and reproducible verification steps.
- If vendor fixes are patchy or delayed, plan for replacement or segmentation strategies; treat EoL gear as high‑priority replacement candidates.
Detection signatures and log indicators (practical examples)
- WebSocket handshake anomalies:
- Repeated or malformed WebSocket upgrade requests from many distinct IPs within short intervals.
- WSS sessions where no authorization headers are present when the server expects BASIC/TLS client certs.
- Authentication flood signatures:
- Greater than N failed auth attempts per minute from same source → alert.
- Exponential backoff not observed on repeated attempts → sign of missing rate limiting.
- Session reuse indicators:
- Two or more concurrent active connections in the back‑end console tied to same CBID.
- State rollback or duplicated Start/StopTransaction messages for the same session ID.
- For Windows jump hosts and management servers:
- Sudden surge in WebSocket client processes or proxy logs indicating unexpected outbound broker connections.
- Auth logs showing failed kiosk/service account password attempts in clusters.
These detection rules should be tuned to reduce false positives and validated in a staging environment before production use.
Critical analysis — strengths, weak points, and residual risks
Strengths
- The advisory identifies concrete, high‑impact root causes that are straightforward to test and remediate (authentication, throttling, session control).
- EVMAPA’s reported remediation of the simultaneous‑session issue (CVE‑2025‑55705) — if verified across deployed hardware — removes a high‑impact race condition.
- The advisory’s alignment with standard ICS mitigation guidance gives operators immediate, operationally tested defensive actions to reduce exposure quickly.
Weaknesses and remaining risks
- Partial vendor responses: ly documented fixes for all findings (notably CVE‑2025‑53968’s lack of a vendor statement in the advisory). Without full vendor confirmation and published fixed firmware builds, operators must assume risk until proven mitigated.
- Implementation complexity: “BASIC authorization control” for OCPP 2.x is a pragecurity depends on implementation details — secure storage of credentials on charge points, mutual TLS support, and correct server enforcement. BASIC auth alone may be insufficient unless combined with TLS client certs or unique per‑device credentials.
- Dependency on network controls: many recommendations (segmentation, VPN) are operational mitigations rather than code fixes. These are effective but place the onus on operators to implement and maintain correctly. Historical ICS incidents show that operational controls frequently lag vendor fixes, leaving windows of exposure.
- Public evidence: the advisory notes “no known public exploitation reported to CISA” at publication tg activity and automated exploitation often precede public reports. Operators must therefore assume a rapid threat lifecycle and prioritize containment even absent confirmed exploitation.
Unverifiable or cautionary items
- Any claim about “all stations of model X fixed as of version Y” must be validated by chware builds on each station and the vendor’s PSIRT bulletin; internal CSAF or vendor text can contain mapping errors that require independent verification before remediation status is certified. Treat vendor‑supplied version numbers as authoritative only after validation.
Windows‑centric implications and operational checklist for enterprise teams
- Engineering workstations and jump hosts often act as therate networks and charging‑station back ends. Harden these hosts:
- Apply least privilege to local per‑user accounts.
- Require MFA for remote access to jump hosts.
- Keep VPN server and client software patched to the latest releases.
- Log collection and correlation on Windows SIEM/EDR agents:
- Ensure WebSocket proxy logs, VPN connection events, and OCPP service logs are forwarded centrally.
- Watch for anomalous scheduled tasks or service account misuse that could indicate an attacker attempting to arm relay tools against charging infrastructure.
- Incident readiness:
- Maintain an image and a test lab where staging patches and vendor fixes can be validated on representative devices before mass rollout.
- Document rollback steps; charging infrastructure and energy flows can be time‑sensitive during peak demand — test change windows carefully.
Conclusion — measured urgency and the operator’s playbook
The EVMAPA advisory is a classic example of critical‑infrastructure software failing on three familiar axes: missing authentication, absent rate limiting, and insufficient session management. Each finding alone is operationally significant; together they form a high‑risk cluster that demands prompt vendor‑verified fixes and immediate operational containment.
Action priorities are clear:
- Confirm vendor‑published fixes and push verified patches.
- Segment and restrict network exposure to charging control systems now.
- Harden authentication (unique keys, TLS, rate limits) and validate session‑enforcement behavior.
- Instrument detection and logging (especially around WebSocket behavior and CBID reuse).
- Treat “no reported exploitation” as a status to monitor, not a reason to deprioritize remediation.
This advisory fits a pattern seen across recent ICS disclosures: straightforward bugs with outsized consequences. Operators who combine immediate network compensations with verified vendor patches and robust detection will reduce risk most effectively. For teams managing Windows jump hosts or enterprise back ends, the immediate focus must be on access controls, patch testing, and building detection rules that surface the exact abuse patterns described in the advisory so that a response can be swift, measurable, and auditable.
Source: CISA
EVMAPA | CISA