A CISA advisory published this week should make every EV fleet operator, charging network manager, and grid security professional stop what they are doing. The vulnerabilities found in Everon's OCPP backends are not edge-case bugs. They are the logical endpoint of an entire industry that built a nationwide energy delivery network and forgot to lock the door.
On March 3, 2026, CISA published advisory ICSA-26-062-08 targeting the OCPP backends of Everon, an EV charging network management company that operated the platform at api.everon.io. The advisory carries a CVSS score of 9.4 — critical. It describes four distinct vulnerabilities in the WebSocket interfaces that charging stations use to communicate with their central management systems. Everon shut down on December 1, 2025, so there is no patch coming. What remains is a clear technical record of exactly how an EV charging backend can be made completely open to unauthenticated attackers — and a reminder that Everon was far from alone in building it this way.
The same week CISA published the Everon advisory, it also released nearly identical advisories against ePower (Ireland), EV Energy (ev.energy, UK), and Mobiliti e-mobi (Hungary). The prior week brought advisories against CloudCharge (Sweden), Mobility46 (Sweden), SWITCH EV, Chargemap, and EV2GO, among others. All of these advisories were reported by the same two researchers: Khaled Sarieddine and Mohammad Ali Sayed of Concordia University. The vulnerabilities across all of them share the same root cause: WebSocket endpoints that fail to require meaningful authentication before accepting commands from anything claiming to be a charging station. This is not a coincidence. It is a pattern baked into how OCPP has been implemented across the industry. Notably, CISA's advisories for ePower and Mobiliti e-mobi explicitly state that those vendors did not respond to coordination requests before publication. The advisories for the other non-defunct vendors do not contain equivalent vendor fix language, suggesting a similar pattern of non-engagement — though the Everon advisory itself is moot given the platform's shutdown.
What OCPP Is and Why It Controls More Than You Think
The Open Charge Point Protocol is the dominant communication standard for EV charging infrastructure globally. It defines how a physical charging station — the device bolted to a wall or standing in a parking lot — exchanges messages with the cloud-based system that manages it. Think of it as the language that lets a charging station say "a car just plugged in," receive a command to start or stop a session, report its power consumption, and accept a firmware update. Without OCPP, charging networks would be a patchwork of proprietary, incompatible hardware. With it, operators can manage thousands of stations from a single dashboard regardless of manufacturer.
The protocol was first published by ElaadNL in 2010 and has gone through several major versions. OCPP 1.6, released in 2015, remains by far the most widely deployed version in the wild. OCPP 2.0 was released in 2018 with security improvements including certificate-based device management and mandatory TLS, but it broke backward compatibility with 1.6. That compatibility break created a problem that persists today: a large installed base of hardware running OCPP 1.6 that cannot simply be upgraded to benefit from newer security architecture. As of January 2025, OCPP 2.1 was released, adding vehicle-to-grid capabilities, but the legacy 1.6 fleet remains the operational reality for the majority of deployed infrastructure.
The U.S. Federal Highway Administration has mandated OCPP use for charging infrastructure funded under the National Electric Vehicle Infrastructure (NEVI) program, a $5 billion initiative to build out a national charging network. New York and California both require OCPP compliance for state-funded charging projects. That mandate creates a direct line between a protocol with documented security weaknesses and publicly funded, publicly accessible critical infrastructure tied to the U.S. power grid.
When a charging station powers on, it initiates an HTTP handshake with the backend that upgrades into a persistent, full-duplex WebSocket connection. From that point on, the station and backend exchange OCPP messages over this channel continuously: status updates, transaction records, remote start/stop commands, and firmware instructions. The station identifies itself to the backend using a charging station identifier — typically a serial number or network-assigned ID. That identifier is how the backend knows which station it is talking to. In a correctly implemented system, the backend would verify the station's identity cryptographically before trusting any messages it sends. In the Everon backend, it did not.
The WebSocket architecture is central to understanding why these vulnerabilities are so damaging. Because the connection is persistent and full-duplex, an attacker who successfully impersonates a station does not just intercept a single transaction — they maintain an ongoing, trusted channel to the backend for as long as the connection is held open. Every command the backend issues to what it believes is a real charger goes to the attacker instead.
The Everon Advisory: Four CVEs, One Attack Surface
Advisory ICSA-26-062-08 catalogs four CVEs, all targeting the same WebSocket attack surface. The researchers who discovered and reported these vulnerabilities — Khaled Sarieddine and Mohammad Ali Sayed of Concordia University — are the same two researchers whose prior academic work in 2024 identified six zero-day vulnerabilities across 16 live EV charging management systems globally. The Everon advisory represents the real-world regulatory consequence of that earlier research making its way through responsible disclosure.
| CVE ID | CWE | Severity | What It Means in Practice |
|---|---|---|---|
| CVE-2026-26288 | CWE-306 | CRITICAL 9.4 | No authentication required to connect to the OCPP WebSocket endpoint. An attacker using a known or discovered station identifier can issue and receive OCPP commands as a legitimate charger. |
| CVE-2026-24696 | CWE-307 | HIGH 7.5 | No rate limiting on authentication requests. Enables brute-force attacks against station identifiers or denial-of-service by flooding the backend and suppressing legitimate charger telemetry. |
| CVE-2026-20748 | CWE-613 | HIGH 7.3 | Session identifiers are predictable and not exclusive. Multiple endpoints can connect using the same identifier. The most recent connection displaces the legitimate station and receives its backend commands — a session shadowing attack. |
| CVE-2026-27027 | CWE-522 | MEDIUM 6.5 | Charging station authentication identifiers are publicly accessible via web-based mapping platforms. These same identifiers are the only prerequisite for impersonating a station under CVE-2026-26288, making their public exposure a direct attack enabler. |
The primary vulnerability, CVE-2026-26288, describes what the advisory calls "missing authentication for a critical function." The OCPP WebSocket endpoint at api.everon.io accepted connections from anything presenting a valid-looking station identifier, with no cryptographic verification of identity whatsoever. An attacker who knew or discovered a station's identifier — information that can be present in captured network traffic, device documentation, or public registries — could connect to the backend and operate as that charger indefinitely.
CISA's advisory states that because no authentication is required, a successful connection via this method can result in privilege escalation, unauthorized control of charging infrastructure, and corruption of charging network data. The absence of any authentication check means the only barrier to full charger impersonation is knowing — or guessing — the station's identifier. Given that CVE-2026-27027 documents those identifiers as publicly accessible via mapping platforms, that barrier is effectively nonexistent.
What makes CVE-2026-20748 particularly insidious is that it enables a silent displacement attack. Because the backend allows multiple connections using the same station identifier and routes commands to the most recent connection, an attacker does not need to terminate the legitimate charger's connection to take over. They simply connect using the same identifier, and the backend starts sending them the commands it was sending the real charger. The real charger is effectively orphaned without any indication anything is wrong. From the backend's perspective, the session looks completely normal.
CVE-2026-27027 closes the loop on the attack chain in a way that deserves more attention than its MEDIUM severity score suggests. The CISA advisory notes that charging station authentication identifiers — the very identifiers required to impersonate a charger under CVE-2026-26288 — are publicly accessible via web-based mapping platforms. This is not a theoretical exposure. EV charging locator apps and mapping services routinely expose station metadata that can include the identifiers the OCPP backend uses for session routing. The consequence: the prerequisite for the highest-severity attack in this advisory is data that any member of the public can retrieve from a charging station locator app on their phone. That is what makes the MEDIUM-rated CVE-2026-27027 functionally critical when chained with CVE-2026-26288.
Chained together, these vulnerabilities create a complete attack path: discover a station identifier (trivial with network access), connect to the WebSocket endpoint without authentication, displace the legitimate charger via session shadowing, and then operate as that charger indefinitely — receiving remote commands, sending fraudulent telemetry, and potentially triggering firmware update sequences that could be weaponized to push malicious code to physical charging hardware.
OCPP 1.6 defines three security profiles with progressively stronger authentication. Security Profile 1 adds HTTP Basic Auth over plaintext WebSocket — the minimum viable identity check. Security Profile 2 requires TLS with Basic Auth, encrypting the channel. Security Profile 3 requires TLS with client-side certificates, providing cryptographic device identity. The Everon advisory describes a system that implemented none of them. Profile 3 is equivalent to the mutual TLS model that security researchers have been recommending since at least 2017. Vendors widely deployed Profile 0 — the absence of any security profile — because OCPP 1.6 made security profiles optional, and "optional" in a cost-competitive deployment environment typically means skipped. The existence of the security profiles in the specification is not a defense of the industry. It is an indictment of a governance model that allowed a protocol used in federally mandated infrastructure to treat authentication as elective.
Everon shut down their platform on December 1, 2025. There is no vendor fix, no coordinated patch timeline, and no ongoing vendor support. CISA's mitigation guidance for this advisory is defensive network hygiene only. Any organization that was using or interfacing with the Everon platform should treat all previously issued station identifiers and credentials as fully compromised and rotate or revoke them accordingly.
This Was Not a Surprise: The Research Trail
What makes the Everon advisory particularly significant is that it does not describe newly discovered behaviors. It describes vulnerabilities that academic security researchers have been documenting, warning about, and publishing peer-reviewed papers on for years. The CISA advisory is the regulatory formalization of a failure mode that was well-understood in the research community long before it showed up in a national warning bulletin.
The foundational warning dates to 2017, when researchers Alcaraz, Lopez, and Wolthusen published "OCPP Protocol: Security Threats and Challenges" in the IEEE Transactions on Smart Grid. That paper argued — nearly a decade ago — that subversion of OCPP endpoints could destabilize power networks, and that the protocol's security properties were inadequate for the critical infrastructure role it was increasingly being asked to play. The paper described spoofing, tampering, and denial-of-service attack vectors that map almost exactly to the CVEs published this week.
In 2023, Alcaraz, Cumplido, and Trivino followed up with a comprehensive analysis of OCPP 2.0.1 using the STRIDE and DREAD threat modeling frameworks, published in the International Journal of Information Security. Even with OCPP's newest version — the one with mandatory TLS and certificate-based device management — the analysis found that meaningful security risks remained, particularly when charging stations connect to microgrids and energy management systems. The researchers concluded that the newer version's security improvements, while real, required hardware upgrades that created adoption barriers and left the 1.6 installed base exposed.
The most directly relevant prior work is the 2024 paper by Sarieddine, Sayed, Torabi, Atallah, Jafarigiv, Assi, and Debbabi — the same Sarieddine and Sayed who reported the Everon vulnerabilities to CISA. Published at ACM AsiaCCS 2024 and conducted in collaboration with researchers at Concordia University and the Hydro-Québec Research Institute, the paper tested 16 live, production EV charging management systems globally and found six zero-day vulnerabilities in each one.
Sarieddine et al., writing in the ACM AsiaCCS 2024 proceedings, argued that government-backed expansion of EV infrastructure had resulted in the rushed integration of a large number of insecure charging stations — a characterization that applies with equal force to the Everon advisory published two years later. The Concordia team's findings included man-in-the-middle attack scenarios, denial of service, firmware theft, and data poisoning — all enabled by the same class of authentication weaknesses and improper session handling that appears in the Everon advisory. They built a physical testbed to demonstrate that attacks on compromised charging stations could be chained to cause disturbances to the power grid itself, not just the charging network. That is not a theoretical claim. It is a demonstrated capability with documented methodology.
A May 2025 paper in the International Journal of Information Security from Hamdare et al. synthesized the existing research landscape and drew a clear conclusion: OCPP carries significant cyber risk stemming from weak authentication mechanisms and improper session handling, and the backward incompatibility of OCPP 2.0.1 with OCPP 1.6 creates practical adoption barriers that keep vulnerable older versions in place. The backward compatibility wall is not a minor inconvenience. It is a structural reason why the Everon class of vulnerabilities persists across the industry even when better alternatives exist on paper.
The Idaho National Laboratory also contributed to this literature with published work on disrupting EV charging sessions and achieving remote code execution via OCPP 1.6 exploits. A 2024 USENIX Vehicle Security workshop paper introduced EmuOCPP, a large-scale emulation framework for testing OCPP security, and used it to independently uncover five new attack paths. The research pipeline on OCPP vulnerabilities is not thin. It is deep, consistent, and has been pointing at the same problems for nearly a decade. The Everon advisory is what happens when the industry does not listen.
The Federal Expansion Problem: Speed vs. Security
The timing of this advisory against the backdrop of U.S. federal EV charging investment is not incidental. The NEVI Formula Program, authorized under the 2021 Infrastructure Investment and Jobs Act, committed $5 billion to building a national network of EV chargers along designated Alternative Fuel Corridors. The Federal Highway Administration required OCPP compliance for all NEVI-funded infrastructure. That mandate created a direct federal dependency on a protocol class that researchers had already characterized as systematically under-secured.
NEVI's deployment has been politically turbulent. In February 2025, the DOT rescinded its previous guidance and froze new funding obligations, with 84% of allocated funds still unobligated at that point. A coalition of 16 states filed suit, and a federal court ordered the freeze lifted in June 2025. By August 2025, FHWA issued revised interim guidance, streamlining requirements and giving states 30 days to resubmit plans. As of late 2025, approximately 384 NEVI-funded charging ports had been built across roughly 80 locations nationwide, with contracts awarded for nearly 4,000 DC fast charger ports at 990 sites. The updated NEVI guidance retained cybersecurity planning as one of only three mandatory elements states must include in their deployment plans — alongside a description of fund use and a community engagement outcomes report. Cybersecurity is statutory. Whether states treat it as more than a checkbox item is a different question entirely.
The NEVI requirement for cybersecurity strategy documentation does not specify what security controls are required. It requires a description of what the state intends to do. That gap between documentation and enforcement is exactly where real-world deployments get built with OCPP 1.6, no mutual TLS, predictable session identifiers, and no rate limiting on authentication — and then receive federal certification as meeting program requirements.
The irony is acute. The federal government required OCPP to ensure interoperability and prevent vendor lock-in. That is a legitimate policy goal. But OCPP's widespread adoption has also meant that every security weakness in the protocol's most deployed version is now embedded in publicly funded, highway-adjacent energy infrastructure that is required by law to be publicly accessible. You cannot restrict access to a public charger on a federal alternative fuel corridor. Anyone with a vehicle — or with a laptop and a network connection — can reach it.
A compromised OCPP backend is not just a billing or service availability problem. Multiple research teams have demonstrated that coordinated manipulation of large numbers of charging stations — forcing simultaneous high-power charging or abrupt stops across a region — can create load fluctuations significant enough to affect grid frequency stability. A sufficiently large botnet of compromised chargers, operated through hijacked OCPP backends, represents a denial-of-service capability against electrical infrastructure. This attack vector was documented in peer-reviewed literature by Sayed, Atallah, Assi, and Debbabi as early as 2022.
The V2G Expansion Makes This Worse, Not Better
OCPP 2.1, released in January 2025, adds native vehicle-to-grid (V2G) capability — the ability for EVs to push power back into the grid. This is a significant policy objective: EVs as distributed battery storage could dramatically improve grid resilience during peak demand. But V2G changes the threat model in a direction that the Everon advisory should make deeply uncomfortable for policymakers.
In a standard charging scenario, a compromised OCPP backend can command a charger to start or stop a session, manipulate billing, or flood the grid with simultaneous demand. In a V2G-enabled scenario, a compromised backend can potentially command vehicles to discharge energy back into the grid on an attacker's schedule — at the wrong time, in the wrong direction, at the wrong voltage. The attack surface expands from "disrupt charging" to "weaponize the vehicle fleet as a grid manipulation tool." OCPP 2.1's V2G features are bidirectional by design. An unauthenticated OCPP backend connection in a V2G-capable deployment is not just a charger impersonation risk. It is a potential grid injection attack vector.
ISO 15118, the standard governing direct communication between the vehicle and the charging station, adds another dimension. ISO 15118 supports Plug & Charge — automatic vehicle authentication using embedded X.509 certificates, removing the need for RFID cards or mobile apps. The security of Plug & Charge depends on a Public Key Infrastructure (PKI) that links vehicle certificates to the backend through a chain of trust. If the backend that anchors that trust chain is accessible without authentication — as in the Everon model — the PKI chain is broken at its foundation. A compromised OCPP backend in an ISO 15118 deployment is not just a charger management problem. It is a certificate authority problem. The attacker controls the trust anchor for vehicle identity in that network segment.
There is a third dimension that most advisory coverage misses: battery degradation as an attack vector. Research from VicOne (2025) documents how a compromised charging station, through V2G communication, can simulate false grid demand signals to trigger rapid, repeated charging and discharging cycles. Each forced cycle accelerates electrochemical wear on the vehicle's battery pack. At scale across a fleet of vehicles connected to attacker-controlled OCPP backends, this is not a theoretical nuisance — it is a mechanism for inflicting slow, deniable physical damage on assets worth tens of thousands of dollars each, with no visible intrusion event and no immediate alarm. The attack surface for OCPP backends in a V2G world is not just grid stability. It is the vehicles themselves.
OCPP 2.1's offline price calculation feature introduces one more wrinkle worth naming. When a V2G-capable station loses backend connectivity, OCPP 2.1 allows it to calculate pricing locally to avoid interrupting service. This feature removes backend oversight during the offline window. A compromised or maliciously configured station could falsify meter readings during that period, overcharging users or providing free service to attackers — with no backend log of the discrepancy. It is a well-intentioned resilience feature that inadvertently opens a billing integrity attack surface.
The Regulatory Enforcement Gap
The Everon advisory names four CVEs and states explicitly that no known public exploitation has been reported to CISA at this time. That phrasing matters. "No known exploitation" does not mean the vulnerabilities were not exploited. It means no reported exploitation reached CISA. For a class of attack — session shadowing — that leaves no visible disruption on either the charger or the backend, the absence of reported exploitation is structurally expected. You cannot detect what you are not looking for, and the behavioral detection rules described in Section 5 of this article are not present in default SIEM deployments.
The broader regulatory landscape has not caught up to what these advisories describe. FERC's June 2025 Order No. 907, approving the new CIP-015-1 standard, requires internal network security monitoring for bulk electric system cyber assets — but EV charging backends do not currently meet the threshold for classification as bulk electric system assets under NERC's CIP framework. They sit in a jurisdictional gap: too networked and grid-adjacent to be dismissed as consumer devices, but not formally regulated as critical grid infrastructure under the CIP standards that govern transmission-level assets. NEVI requires cybersecurity planning documentation. CIP-015-1 requires network monitoring for qualifying grid assets. Neither standard currently reaches the OCPP backend layer where these six CISA advisories are concentrated.
In Europe, NIS2 — the EU's updated Network and Information Security Directive — classifies EV charging operators with significant infrastructure presence as "important entities" subject to risk management and incident reporting requirements. That creates a materially different enforcement environment for European CPOs than the descriptive-plan model that governs U.S. NEVI deployments. The divergence is not merely regulatory philosophy. It affects whether a CPO that runs an unauthenticated OCPP backend faces a compliance liability or merely a security recommendation.
There is also a supply chain dimension that the advisory framework does not address. In May 2025, U.S. energy officials reported discovering undocumented cellular communication devices embedded in Chinese-manufactured solar power inverters — components not disclosed in product documentation and capable of bypassing network firewalls. The EV charging hardware supply chain faces an analogous risk. A charging station that appears to implement OCPP correctly but contains a covert communication channel is immune to every compensating control described in defensive guidance: network segmentation, mTLS, rate limiting. None of those controls operate on a channel you do not know exists. Hardware procurement for NEVI-funded infrastructure needs supply chain attestation requirements, not just protocol compliance documentation.
What Defenders Need to Do Right Now
CISA's general ICS hardening guidance applies directly here, but there are specifics worth calling out for organizations operating or securing EV charging infrastructure.
The highest-impact immediate control is network isolation. Charge management endpoints — the WebSocket backends that charging stations connect to — should never be directly reachable from the public internet. Place them behind firewalls with strict ingress rules, ideally with management access restricted to known IP ranges via allowlist. Many operators deployed these backends with open public endpoints for convenience during initial rollout and never revisited the decision. That exposure needs to be addressed before anything else.
For remote access to charging infrastructure management, require VPN with multi-factor authentication. Recognize that VPNs are not a complete solution — they are a perimeter control, not an authentication substitute for the OCPP backend itself. The backend still needs to verify charger identity independently of whether the management console is accessed via VPN.
The durable fix for the class of vulnerabilities in the Everon advisory is mutual TLS with certificate-based charger authentication. In this model, both the backend and the charging station present certificates during the WebSocket handshake, and neither side accepts the connection unless the other's certificate is valid and trusted. OCPP 2.0.1 supports this natively. For hardware locked to OCPP 1.6, the May 2025 Hamdare et al. research proposed a security framework that retrofits stronger authentication into older protocol versions without requiring hardware replacement — a practically important contribution given how much 1.6 hardware remains deployed.
Monitor for behavioral anomalies that indicate session shadowing or charger impersonation. Specific indicators include duplicate connections using the same station identifier, a station that stops reporting telemetry while the backend continues to receive responses on that session, unexpected OCPP action types for a given station (bulk firmware update requests, mass remote start/stop commands issued outside of normal operational hours), and rapid sequential authentication attempts against multiple station identifiers. These patterns should be fed into SIEM workflows with automated alerting.
Treat station identifiers as sensitive data. Under the Everon vulnerability model, knowing a station's identifier is the only prerequisite for impersonating it. Station ID assignment processes, device documentation, and any systems that log or expose station identifiers should be reviewed. Where possible, implement identifier rotation and backend-side revocation capability so that a compromised identifier can be invalidated without taking the physical hardware offline.
Finally, any organization that shared credentials, API keys, or station identifiers with Everon's platform prior to its December 2025 shutdown should treat those values as fully compromised and rotate them immediately. Everon is gone, but the data it held is not necessarily gone with it.
Beyond the Basics: What Deeper Remediation Actually Looks Like
The standard CISA mitigation guidance — network isolation, VPN with MFA, mTLS — is necessary but not sufficient if you stop there. Defenders with mature programs should go further in three directions that are rarely discussed in general advisory coverage.
First, implement OCPP Security Profile enforcement at the backend level with hard rejection of unauthenticated connections. This sounds obvious, but many backend deployments are configured to accept connections under any security profile, including none, in the name of backward compatibility with older hardware. Backward compatibility with OCPP 1.6 hardware does not require accepting Profile 0 connections — it requires that your 1.6 hardware be configured to connect under at least Profile 2. Any 1.6 hardware that cannot be configured to use TLS with Basic Auth is a liability that should be flagged for replacement planning, not accommodated by weakening backend security.
Second, treat station identifier enumeration as an active threat intelligence collection opportunity. Under the Everon model, identifiers leaked via mapping platforms are the first link in the attack chain. Operators should actively monitor EV charging locator APIs and mapping datasets that reference their stations to understand what identifier information is publicly indexed. Where mapping platform APIs allow identifier suppression or pseudonymization, implement it. Where they do not, use that exposure as the risk metric for prioritizing network isolation and backend authentication hardening.
Third, build OCPP-aware anomaly detection into your SOC playbooks, not just generic network monitoring. Generic anomaly detection will not catch session shadowing because the network traffic looks normal — a WebSocket connection with valid OCPP message structure. OCPP-specific detection rules need to trigger on: station identifiers that appear in two concurrent sessions, BootNotification messages that arrive for an already-registered station outside of a maintenance window, firmware update requests that originate from the backend rather than an authenticated management console, and MeterValues that show discontinuous readings from the same session. These are the behavioral fingerprints of the specific attack classes documented in the Everon advisory. They will not appear in default SIEM rule sets.
Key Takeaways
- Everon is the example, not the exception. In the two weeks surrounding the Everon advisory, CISA published nearly identical advisories against at least seven other EV charging backend providers: ePower, EV Energy, Mobiliti e-mobi, CloudCharge, Mobility46, SWITCH EV, Chargemap, and EV2GO. Every advisory was reported by the same two researchers. The root cause — unauthenticated WebSocket endpoints in OCPP backends — is an industry-wide pattern documented in peer-reviewed security research since 2017. Treating this as an Everon problem misses the point entirely.
- The research community saw this coming. Concordia University researchers Sarieddine, Sayed, and their seven-person team, who reported these vulnerabilities to CISA, were also behind a 2024 academic paper demonstrating the same vulnerability class across 16 live charging management systems globally. The technical knowledge to fix these problems existed. The industry-wide pressure to act on it did not.
- Federal OCPP mandates create federal security exposure. NEVI-funded charging infrastructure is required to use OCPP, required to be publicly accessible, and is physically embedded in highway-adjacent critical infrastructure. The security requirements in state deployment plans are descriptive, not prescriptive. That gap needs to close before the next wave of federally funded deployments comes online.
- Session shadowing is a silent attack. CVE-2026-20748 (CVSS 7.3, HIGH) enables an attacker to displace a legitimate charging station from its backend session without any visible disruption. The charger and the backend both continue operating normally from their own perspectives. Detection requires active monitoring for duplicate session identifiers and behavioral telemetry anomalies — not passive logging. "No known exploitation" in CISA's language means no reported exploitation reached CISA — not that exploitation has not occurred.
- The MEDIUM-rated CVE completes the kill chain. CVE-2026-27027's 6.5 score understates its operational impact. The fact that charging station authentication identifiers are publicly accessible via mapping platforms means the prerequisite for the highest-severity attack in this advisory is data anyone can retrieve from a charger locator app. Severity scores measure individual vulnerabilities in isolation; chained with CVE-2026-26288, CVE-2026-27027 is functionally critical.
- V2G makes the threat model significantly worse — including battery damage. OCPP 2.1's vehicle-to-grid capabilities transform an unauthenticated backend connection from a charger management problem into a potential grid injection attack vector. A compromised backend can also trigger forced charge-discharge cycles that accelerate battery degradation in connected vehicles — inflicting slow, deniable physical damage with no visible intrusion event. The attack surface extends from disrupting charging to destroying assets.
- The regulatory framework has a jurisdictional gap. FERC's CIP-015-1 network monitoring standard covers bulk electric system assets. NEVI requires cybersecurity planning documentation. Neither standard currently reaches the OCPP backend layer where these six advisories are concentrated. EV charging backends operate in a gap between consumer device regulation and critical infrastructure protection. That gap is where these attacks live.
- Mutual TLS is the fix; network isolation buys time. Certificate-based mutual authentication between chargers and backends eliminates the authentication bypass class entirely. For hardware that cannot support OCPP 2.0.1, academic frameworks now exist to retrofit stronger authentication into OCPP 1.6 deployments. Until that work is done, aggressive network segmentation, backend access controls, and OCPP-aware anomaly detection are the most effective compensating controls available.
The EV charging industry built a network fast because it had to. Federal funding, state mandates, and consumer demand created a deployment environment where interoperability and speed were the primary metrics. Security was not ignored maliciously — it was deprioritized structurally, in ways that are now visible in six CISA advisories from two consecutive weeks, all reported by the same research team. The research trail on OCPP vulnerabilities is long, the attack surface is wide, and the infrastructure is now federally mandated and publicly accessible. OCPP 2.1 and the coming wave of V2G deployments will expand that attack surface further — adding battery degradation, grid injection, and PKI compromise to a threat model that already included session hijacking and denial of service. The regulatory framework that governs this infrastructure does not currently reach the OCPP backend layer. The hardware supply chain is not being verified for undisclosed communication components. And the authentication failures documented in these six advisories have a known fix and no excuse for remaining unaddressed. Every NEVI-funded station that comes online without mutual TLS and OCPP-aware monitoring is, in the ways that matter, replicating the conditions the Everon advisory describes — with federal dollars behind it.
Sources & Further Reading
- CISA, ICS Advisory ICSA-26-062-08: Everon OCPP Backends, March 3, 2026.
- CISA, ICS Advisory ICSA-26-062-07: ePower epower.ie, March 3, 2026.
- CISA, ICS Advisory ICSA-26-062-06: Mobiliti e-mobi.hu, March 3, 2026.
- CISA, ICS Advisory ICSA-26-057-07: EV Energy ev.energy, February 26, 2026.
- CISA, ICS Advisory ICSA-26-057-03: CloudCharge cloudcharge.se, February 26, 2026.
- CISA, ICS Advisory ICSA-26-057-08: Mobility46 mobility46.se, February 26, 2026.
- Sarieddine, K., Sayed, M.A., Torabi, S., Attallah, R., Jafarigiv, D., Assi, C., Debbabi, M., "Uncovering Covert Attacks on EV Charging Infrastructure: How OCPP Backend Vulnerabilities Could Compromise Your System," ACM AsiaCCS 2024.
- Hamdare, S. et al., "Cyber defense in OCPP for EV charging security risks," International Journal of Information Security, May 2025.
- Alcaraz, C., Cumplido, J., Trivino, A., "OCPP in the spotlight: threats and countermeasures for electric vehicle charging infrastructures 4.0," International Journal of Information Security, 2023.
- Alcaraz, C., Lopez, J., Wolthusen, S., "OCPP Protocol: Security Threats and Challenges," IEEE Transactions on Smart Grid, Vol. 8, No. 5, 2017.
- Boussaha, S. et al., "Effective and Scalable OCPP Security and Privacy Testing," USENIX VehicleSec 2025.
- Wikipedia, Open Charge Point Protocol. Accessed March 2026.
- Federal Highway Administration, National Electric Vehicle Infrastructure (NEVI) Formula Program. Accessed March 2026.
- Congressional Research Service, "Status of Federal Implementation of EV Charging Infrastructure," 2025.
- Sayed, M.A., Atallah, R., Assi, C., Debbabi, M., "Electric vehicle attack impact on power grid operation," International Journal of Electrical Power & Energy Systems, Vol. 137, 2022.
- VicOne, "Securing the Charge: Hidden Risks in ISO 15118," VicOne Research, 2025. (V2G battery degradation attack vectors and OCPP 2.1 offline pricing risks.)
- Federal Energy Regulatory Commission, Order No. 907, approving CIP-015-1 (Internal Network Security Monitoring), June 26, 2025.
- Paren / Inside EVs, "Our Bruised Federal EV Charger Program Just Had A Comeback Year," January 2026. (NEVI deployment numbers.)
- Atlas Public Policy, "The Next Steps with Federal EV Charging Programs," October 2025. (NEVI deployment metrics as of September 2025.)
- Open Charge Alliance, OCPP 2.1 Specification, January 2025.