A new cluster of high‑severity vulnerabilities in the Everon OCPP backends has put a large swath of EV charging infrastructure squarely in the crosshairs of operators, fleet managers, and national‑scale network defenders — the flaws allow unauthenticated attackers to impersonate charging stations, issue OCPP commands, hijack sessions, and in some cases escalate to administrative control of charging networks, creating real-world risks to availability, billing integrity, and grid stability. ://www.tenable.com/cve/CVE-2026-27028)
Background / Overview
The advisory cataloged by U.S. industrial cybersecurity authorities identifies multiple, related weaknesses in the Everon OCPP backend (identified in the advisory as api.everon.io), classed together because they expose the same attack surface: the backend interfaces that charging stations use to register, authenticate, and exchange control messages with central systems. The reported weaknesses include
Missing Authentication for Critical Function,
Improper Restriction of Excessive Authentication Attempts (brute‑force protection failures),
Insufficient Session Expiration, and
Insufficiently Protected Credentials — a grouping that, when present together, dramatically expands what an attacker can do once thcted endpoints.
The advisory assigns a critical severity rating to the most consequential issue — an OCPP WebSocket authentication bypass — and links it to at least one CVE record that scores in the high‑nines (CVSS ≈ 9.4), signaling that exploitation is both remotely feasible and capable of causing major confidentiality and integrity losses across charging networks.
Everon’s OCPP backend is widely used, often integrated as the charge‑point management layer for both commercial deployments and consumer-grade public chargers. That footprint, combined with the fact that many charge points are left reachable across public networks (or via poorly segmented corporate networks), is what elevates this from a technical vulnerability to an operational emergency for some operators.
What exactly is broken — technical breakdown
1) OCPP WebSocket endpoints without proper authentication
At the center of the advisory is a
WebSocket authentication bypass: the backend’s OCPP WebSocket endpoints accept incoming connections and process OCPP messages using a short or predictable station identifier without performing any robust station authentication or authorization check. In practice, this means an unauthenticated remote actor who can reach api.everon.io can open a WebSocket and begin sending OCPP commands as though they were a legitimate charger, or listen to messages destined for that charger. This is
not a minor API bug — it's a direct impersonation vector.
Why WebSockets matter: OCPP (Open Charge Point Protocol) relies on long‑lived bi‑directional channels (WebSocket or similar) for real‑time command/response messages (start/stop session, meter values, firmware updates). If that channel is accepted without strong identity verification, the backend has no reliable way to distinguish a real charger from a spoofed client. Attackers can therefore simulate charge sessions, fake meter data, or inject control commands.
2) Missing limits on authentication attempts anory also notes failures in throttling authentication attempts and in limiting concurrent or stale sessions. In plain language: an attacker can brute‑force or repeatedly attempt connections without meaningful rate‑limiting, and existing session tokens or channels do not expire reliably. This increases the window of exposure and makes mass‑automation effective. Combined with default or exposed credentials, this is how small weaknesses become large‑scale compromises.
3) Insufficiently protected credentials and session tokens
Wevice endpoints store or transmit credentials without adequate encryption and access controls, those secrets can be recovered and re‑used. The advisory points to weaknesses in credential protection and session handling that permit token replay, credential disclosure, or session reuse across multiple devices. In OCPP deployments, leaked backend credentials enable attackers to impersonate
operators or to take control of entire tenant accounts.
Realistic attack scenarios and potential impact
The theoretical attack paths are straightforward; the operational consequences are where the risk becomes acute.
- Station impersonation and fraud: An attacker connects to the backend using a known station ID, reports false charging sessions or manipulates meter data to steal electricity or defraud charging marketplaces. This can result in revenue loss and billing disputes for site owners and payment processors.
- Remote administrative takeover: Where mass‑assignment or role‑escalation vectors exist (historically observed in some OCPP backends), attackers who can inject crafted requests may elevate themselves to admin roles and then push broad configuration changes — disabling chargers, redirecting firmware updates, or changing pricing rules. Historical research into OC that APIs lacking hard role enforcement allow this kind of escalation.
- Denial‑of‑service (DoS) and supply‑side effects: Attackers can terminate sessions, force chargers offline, or synchronize stop commands across many points — leading to localized service outages and in extreme cases contributing to load balancing problems or grid strain if many chargers are toggled simultaneously. The advisory explicitly warns about the plausibility of DoS-style impacts.
- Firmware theft and malicious updates: If an attacker can impersonate a charger or an operator, they may be able to request firmware downloads or force updates that reveal proprietary binaries — or, worse, push malicious fiigning is weak or absent. Prior research into charging infrastructure vulnerabilities has repeatedly highlighted firmware as a high‑value target.
- Broader systemic and safety risks: Public chargers are embedded in the energy and transport ecosystems; sustained outages or widespread manipulations that alter charging rates could have cascading consequences for fleet availability and, in edge cases, grid stability during peak demand windows. These are not immet they are credible risks given large deployments and poor segmentation.
Who reported this and what CVEs are assigned
Public advisories and CVE databases list multiple identifiers tied to related issues in OCPP backends; at least one high‑severity CVE (scored in the 9.0+ range) describes the WebSocket authentication bypass. The advisory credits researchers who reported these issues to authorities and the vendor; reviewers should treat vendor coordination notes and CVE descriptions as the primary canonical source for the technical specifics while using independent vulnerability databases to corroborate severity and exploitability.
Note: CVE allocation and vendor advisories for complex, multi‑vector issues sometimes produce multiple CVE IDs across vendors and platforms; defenders should consult authoritative CVE/NVD entries and the vendor’s CSR/CSAF files for fix timelines.
How operators should respond now — prioritized checklist
The CISA advisory (and standard ICS hardening guidance) sets out practical mitigations intended to reduce the exploitation while vendors produce and distribute fixes. Here’s a prioritized, actionable checklist tailored to EV charging operators and site owners.
- Isolate and restrict access immediately
- Remove direct internet exposure for any charge‑management endpoints and related infrastructure.
- Place chargers and the CMS behind segmented networks and strict firewall policies. Use allowlists for management IPs only. This is the highest‑impact immediate control.
- Apply defense‑in‑depth on remote access
- Where remote access is required, use hardened VPNs or secure jump hosts with multi‑factor authentication (MFA), and ensure those access methods are patched and monitored. Recognize VPNs are only as secure as their endpoints.
- Harden backend authentication and session controls
- Enforce mutual authentication between chd (certificate‑based authentication or securely provisioned device keys).
- Implement strict session expiration, single‑use tokens, and protections against session replay and simultaneous sessions for the same device ID.
- Rate‑limit and block brute‑force attempts
- Add robust throttling and account lockout policies for station and operator authentication attempts. Use anomaly detection to flag high‑velocity connection attempts to WebSocket endpoints.
- Rotate and protect crecredentials and keys, migrate any plaintext or weakly protected secrets to secure vaults, and prohibit the hard‑coding of credentials in device firmware or public repositories.
- Logging, monitoring, and detection
- Log WebSocket connections and OCPonitor for unknown IPs, multiple concurrent sessions for the same station ID, and unusual command patterns (bulk start/stop, repeated firmware requests).
- Integrate OCPP telemetry into SIEM or SOC workflows with alerting on anomalies.
- Coordinate with vendors for patches and mitigations
- Engage the vendor’s security contact and follow any vendor patches/mitigations. If the vendor has not provided a timely fix, increase compensating controls and consider migration to alternative backends for high‑risk chargers.
- Prepare an incident response plan specific to charging infrastructure
- Develop procedures for isolating compromised chargers, revoking affected credentials, and recovering meter and billing data integrity. Test those steps in tabletop exercises.
For many operators, the quickest effective step is network isolation and firewalling of management endpoints; this both prevents many remote exploitation scenarios and gives time to implement more durable fixes like mutual TLS or token‑based device authentication.
Detection: what to hunt for in your logs
- Unexpected WebSocket handshakes: connections from unknown public IPs that successfully upgrade to OCPP subprotocols.
- Concurrent sessions using the same station ID from geographically dispersed IPs.
- Sudden bursts of session creation or authentication attempts (an indicator of brute‑force or automated scanning).
- Replayed or duplicated meter readings and improbable session durations or energy values (fraud indicators).
- Unauthenticated requests for firmware or mass configuration changes.
If you find any of these patterns, assume compromise until proven otherwise: isolate, snapshot logs and configuration, and begin forensic capture of relevant telemetry.
Vendor and ecosystem context — why this keeps happening
The EV charging ecosystem is a mix of legacy device designs, rapid market growth pressures, and diverse suppliers — many components were originally designed for functionality and cost rather than enterprise‑grade security. Past audits and penetration testing across multiple vendors have repeatedly uncovered
authentication gaps, predictable device IDs, and weak API authorization that enable account hijacks or charger takeover. That historical precedent makes the current Everon advisory less surprising and more urgent: similar mistakes continue to manifest at scale unless the protocol integrations are hardened by design.
Complicating remediation, some vendors’ business models tie continued charger operation to hosted backends. When a backend has a vulnerability or a vendor winds down a service, site owners can be faced with painful migrations or offline chargers unless contingency plans are in place. This dynamic increases the operational risk when vulnerabilities are disclosed. (
tapelectric.app)
Critical analysis — strengths, weaknesses, and blind spots
Strengths of the advisory and response
- The advisory correctly groups related flaws (auth/authz, session management, credential protection) because real attacks chain these weaknesses together; addressing them as a cluster is technically sound.
- Issuing a high severity score for the WebSocket bypass forces immediate prioritization and aligns with ICS risk posture (high impact of remote manipulation).
Weaknesses and lingering concerns
- Public details show the affected component is a cloud backend — while cloud vendors can patch quickly, many operators still use on‑prem device management bridges or older firmware that cannot be updated remotely, which limits the practical reach of vendor patches.
- The advisory emphasizes network controls and VPNs as mitigations, but these are compensating controls; they do not fix protocol design faults. Overreliance on perimeter controls risks leaving many devices exposed due to misconfiguration or neglected TLS/VPN endpoints.
Blind spots operators must consider
- Supply chain and roaming: the charging ecosystem relies on roaming protocols (OCPI, OCPP interoperability). A vulnerability in one backend that’s allowed to roam can propagate trust and access to other networks if tokens or session cookies are accepted across systems.
- Legacy hardware: chargers that can’t be updated or that embed credentials in readable flash memory remain a persistent threat. Physical access to such devices continues to enable firmware extraction and credential recovery. Historical pen‑tests show this is a recurring failure mode.
For security teams: a medium‑term remediation plan (30–90 days)
- Inventory and classify
- Map all chargers, their backend endpoints (including any third‑party backends), firmware versions, and whether they accept remote updates.
- Apply immediate isolation for at‑risk endpoints
- Put affected backend endpoints behind strict perimeter controls, and where possible force management channels through a hardened VPN with MFA and dev3. Implement device identity and mutual authentication
- Plan and begin deploying certificate‑based identity for chargers; replace any shared or static credentials.
- Patch and replace
- Work with vendors to roll out patches; where no patch is available and an endpoint is reachable from the internet, plan charger migration or decommissioning.
- Continuous detection and recovery
- Integrate OCPP channel telemetry into SOC workflows and run regular red‑team tests focused on station impersonation and session replay.
- Governance and contracts
- Update procurement and vendcurity requirements (signed firmware, efficient patch channels, incident SLA, evidence of secure development practices).
What we don’t know — and what to watch for
- Public proof‑of‑concept exploits: as of the publication of the advisory, authorities reported no known public exploitation, but the presence of multiple easy‑to‑automate failure modes (predictable IDs, unthrottled endpoints) makes it likely that low‑sophistication attackerse issues quickly in the wild if they find reachable targets. Operators should assume active scanning will follow public advisory release.
- Full vendor response timelines: vendor coordination and staged patching are ongoing; operators must reconcile vendor timelines with their own risk tolerance and apply compensating controls where patches cannot be deployed immediately. Check vendor bulletins and CSAF releases for definitive patch guidance. (github.com)
Final recommendations — a checklist for immediate action
- Block internet access to api.everon.io and other charge‑management endpoints unless specifically required for operations; if needed, restrict access to an explicit allowlist of management hosts.
- If you cannot immediately isolate, enforce strict VPN access with MFA and monitor for anomalous WebSocket traffic.
- Deploy logging and alerting for duplicate sessions, rapid authentication failures, and atypical OCPP actions (bulk firmware requests, mass start/stop commands). ([tenableable.com/cve/CVE-2026-27028)
- Rotate any exposed keys; treat all station identifiers as potentially leaked and enforce revocation/renewal where supported.
- Coordinate with your vendor and peers: share indicators, ask for concrete patch ETA, and demand signed firmware and strong device identity as part of remediation.
Conclusion
The vulnerabilities affecting Everon’s OCPP backend underscore a hard truth: the convenience and rapid interoperability of the EV‑charging ecosystem have outpaced secure design in many deployments. A small set of defects — weak or missing authentication, permissive session handling, and poorly protected credentials — can be chained into administrative takeover and large‑scale disruption. Operators must treat the advisory as an urgent operational risk: isolate, detect, and harden now; patch and rearchitect for device identity and mutual authentication next. The good news is that many of the recommended mitigations are well understood and practically achievable: network segmentation, tokenized device identity, strong session controls, and vigilant monitoring will blunt exploitation while vendors deliver patches. What remains non‑negotiable is speed: with a critical CVE score and a readily reachable attack surface, action delayed is risk multiplied.
Source: CISA
Everon OCPP Backends | CISA