A newly published advisory from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) warns that ePower’s charging management platform — branded at epower.ie and used by network operators and site hosts worldwide — contains a cluster of high‑severity authentication and session‑management vulnerabilities that could let unauthenticated attackers take administrative control of chargers or effectively disrupt charging services through denial‑of‑service techniques. CISA classifies the issue as severe (CVSS-level impact described as near‑critical) and lists broad categories of failure — missing authentication for critical functions,
no effective rate limiting, overly long session lifetimes, and improperly protected credentials — affecting all versions of the product cited in the advisory. The advisory was released on March 3, 2026 and flags immediate operational risk to EV charge‑point operators, site owners, and utilities relying on ePower’s systems. /feedly.com/cve/CVE-2026-27770)
Background / Overview
The electrification of transport depends on a growing, distributed fleet of public and private charging stations controlled by management platforms that mediate authentication, telemetry, and command-and-control. Those platforms typically expose real‑time interfaces — often OCPP (Open Charge Point Protocol) over WebSocket or HTTP APIs — which pair operator consoles and back‑end services with fielded chargers. When these surfaces lack robust authentication, session hygiene, and credential protection, they become a direct attack path into the operational fabric of charging networks. The CISA advisory highlights this systemic risk by naming ePower’s management endpoints as having precisely these weaknesses: unauthenticated access to critical functions, absent or weak throttle/lockout controls, session tokens that fail to expire appropriately, and stored credentials that are insufficiently protected.
ePower is an Irish EV charging and solar company with commercial deployments across Ireland and a growing presence in public and private charging sites. The vendor’s footprint in retail, hospitality, and motorway service locations means a vulnerability in its management plane has the potential to impact a large number of charge points and their site operators. For context on vendor size and deployments, ePower lists operations and customer-facing activity in Ireland and has a public company profile consistent with being a mid‑sized operational provider in the sector.
CISA’s advisory follows the same template and mitigation recommendations it has used for other industrial control system advisories this year: urging network isolation, restricting internet exposure, and applying layered defenses to reduce the chance an unauthenticated internet‑accessible endpoint can be abused to cause operational impact. This advisory is part of a continuing series of CISA alerts that have repeatedly highlighted authentication and session management as a dominant failure mode for operational technology and distributed infrastructure.
What CISA says is wrong — the technical summary
CISA groups the ePower weaknesses into four principal categories. Each represents a well‑understood security failure whose exploitation yields different operational outcomes.
- Missing Authentication for Critical Function — sensitive endpoints do not require valid operator or device authentication before performing privileged actions. In charging‑management systems this can include commands that start or stop charging, alter pricing/authorization, or change firmware/registration state of a charger. When such endpoints accept unauthenticated requests, an attacker can impersonate a legitimate charger or operator and issue commands as if they were an authorized actor.
- Improper Restriction of Excessive Authentication Attempts — no effective rate‑limits or account lockouts for failed logins or token requests. This allows brute‑force or credential‑coercion attacks (including automated credential stuffing) to succeed at scale. Attackers can iterate credentials or session tokens against an endpoint and eventually win valid credentials or session states. The absence of throttling also enables different denial‑of‑service techniques: deliberately hammer authentication endpoints to prevent legitimate logins.
- Insufficient Session Expiration — session tokens remain valid far beyond safe operational windows, or sessions are not invalidated after key lifecycle events (logout, password change, administrator role changes). Long-lived sessions increase the window for token theft and replay. In practice, session token reuse or replay against WebSocket/OCPP endpoints can result in session hijacking, allowing an adversary to take over an operator session or masquerade as a charger.
- Insufficiently Protected Credentials — secrets and stored credentials (for chargers, integrators, or backend service accounts) are not protected at rest or in transport. This includes weak or absent encryption of database fields, poor key management, or storage of static shared secrets embedded in client or server code. Compromise of these secrets yields credential harvesting and lateral movement opportunities.
CISA’s advisory warns these failures, combined, enable a number of attack chains including complete administrative takeover of chargers, billing manipulation, telemetry spoofing (hiding malicious activity), and wide‑scale denial of charging services. The agency notes the affected component is used in critical sectors — energy and transportation — amplifying potential consequences if exploited.
Why these findings matter: practical attack scenarios
To translate abstract categories into operational risk, consider the following realistic attack scenarios enabled by the vulnerabilities CISA describes:
- Charger impersonation via WebSocket/OCPP: an unauthenticated attacker connects to the charge-control WebSocket endpoint using a known charger identifier and exchanges OCPP commands. From there the attacker can:
- Send remote StartTransaction/StopTransaction commands to disrupt service.
- Push arbitrary telemetry that masks sabotage or billing fraud.
- Receive remote firmware updates (if the firmware workflow is insufficiently authenticated) and attempt to introduce persistent malicious logic.
This precise vector — connecting as if you were a real station by exploiting unauthenticated WebSockets — is called out in early CVE reporting for the issue and matches patterns CISA warns about.
- Credential stuffing / brute‑force to obtain a management account: absent rate limits, an attacker automates login attempts for a management user or API token. Successful login yields administrative GUI/API access to all chargers managed by the account, enabling mass configuration changes, stopping chargers, or creating fraudulent transactions. The attacker can then use harvested credentials to pivot into adjacent corporate networks.
- Session replay / token theft: long session lifetimes or failure to properly invalidate sessions means a stolen token (from browser storage, logs, or misconfigured caches) remains useful. An attacker who intercepts a valid token — or extracts it via a compromised device — can operate as the legitimate user until expiry or explicit revocation. In OCPP/WebSocket contexts this is functionally equivalent to a live operator session takeover.
- Mass denial of service by abusing authentication surfaces: by repeatedly hitting authentication endpoints or opening many WebSocket connections and keeping them alive, an attacker can saturate backend resources and prevent legitimate users and stations from connecting, leading to partial or total loss of charging capacity at affected sites. This has real grid and customer‑service implications during peak demand periods.
These scenarios are not theoretical: in the broader ICS/OT space, attackers frequently chain weak authentication with telemetry manipulation and lateral movement to create high-impact incidents. CISA has repeatedly highlighted similar exploit patterns in prior advisories and incident briefs.
Validation and cross‑references — what we can confirm today
- CISA published an advisory on March 3, 2026 that lists ePower (epower.ie) as affected by a coordinated group of authentication and session‑management vulnerabilities impacting all versions of the product. The advisory text describes the four vulnerability categories summarized above and issues staidance. The advisory explicitly notes no known public exploitation was reported at the time of release.
- Emerging CVE tracking services have already created entries (for example, CVE‑2026‑27770 is being tracked in industry feeds) that reference the same classes of WebSocket/OCPP authentication failures for ePower; however, as of the advisory release the public CVE descriptions and scoring artifacts were still incomplete in some repositories, and some entries lacked full CVSS vectors. That means the community has recognized specific CVEs are associated with the advisory, but authoritative CVE details may still be rolling out. Treat any early CVE entries as provisional until vendor and NVD entries are published/confirmed.
- CISA’s mitigation recommendations for ePower mirror those it has published for other ICS advisories this year: reduce internet exposure of control systems, isolate control networks behind firewalls, prefer secure remote access methods (VPNs with caveats), and apply layered defenses and monitoring. These are consistent across multiple CISA ICS advisories and form the baseline industry guidance for emergency response to such findings.
Because some CVE records and technical PoCs may be incomplete or still under embargo, we flag any specific exploit claims that cannot be independently verified in public CVE or vendor advisories. Where official vendor fixes or patches are not yet published, operators should assume the worst — treat the advisory as actionable and apply mitigations immediately.
Immediate action checklist for operators and site hosts
If you operate ePower-managed chargers, perform the following steps immediately. These are ordered by urgency and each entry includes
why it matters and
how to do it quickly.
- Inventory exposed endpoints (Why: determine internet exposure)
- Scan for publicly reachable management/edge endpoints and WebSocket/OCPP ports. Prioritize anything reachable from untrusted networks.
- If endpoints are publicly reachable, assume they are exploitable until proven otherwise.
- Isolate charging infrastructure from the internet (Why: eliminate remote unauthenticated access)
- Place management/back‑end systems on segmented networks, behind firewalls and jump hosts. Remove direct inbound access.
- Where possible, restrict access to specific vendor‑approved management IPs and administrative subnets.
- Enforce multi‑factor authentication (MFA) on all operator and admin accounts (Why: reduces credential stuffing success)
- If the platform supports MFA, enable it for all accounts with management privileges. If it does not, adopt compensating controls (VPN + IP allowlisting) and treat platform credentials as high‑risk secrets.
- Apply strict rate limiting and account lockout (Why: prevent brute force)
- Configure upstream WAFs or API gateways to enforce throttling and lockout policies for authentication endpoints if the vendor application cannot be updated immediately.
- Shorten session lifetimes and revoke stale sessions (Why: limit token replay window)
- Lower session timeouts, enforce reauthentication for sensitive operations, and perform proactive session invalidation for high‑privilege accounts.
- Rotate and protect secrets (Why: limit credential reuse and lateral movement)
- Rotate any shared or embedded secrets, ensure storage uses encryption with proper key management, and avoid sharing admin credentials between corporate and control zones.
- Increase logging, monitoring, and alerting (Why: detect abuse quickly)
- Enable detailed auth and WebSocket logging, set alerts for anomalous patterns (multiple failed auth attempts, new device registrations, unusual command rates).
- Coordinate with ePower and report findings to authorities (Why: vendor patching and sector awareness)
- Follow vendor guidance and coordinate with national CERTs where appropriate. CISA encourages reporting suspected malicious activity to help correlate incidents.
Operators should treat the advisory as an emergency: even absent reported exploitation at publication time, the nature of the defects makes automated mass exploitation plausible once technical details are widely known.
Longer‑term technical recommendations (for vendors, integrators, and network architects)
The root causes CISA identifies are not unique to one vendor — they’re architectural shortcomings that require product, process, and network fixes.
- Adopt authenticated, mutually verified device registration for OCPP/WebSocket channels. Each charger should authenticate using per‑device X.509 client certificates or comparable cryptographic device credentials; server‑side checks must reject unauthenticated connection attempts.
- Implement robust token lifecycles: short lived tokens, refresh tokens with rotating signatures, and mandatory reauthentication for control plane actions.
- Use rate limiting, CAPTCHAs for human interfaces, and progressive lockout for automated interfaces; pair with anomaly detection to distinguish legitimate bulk management operations from abuse.
- Protect credentials with proven key management: hardware security modules (HSMs) or cloud KMS for secret storage, and avoid static secrets in device firmware or client code.
- Harden WebSocket and API surfaces with API gateways, WAFs, and zero‑trust access models that enforce policy before requests reach backend management systems.
- Build a secure update and signing process for firmware and configuration pushes: authenticate and sign firmware packages; perform integrity checks before applying updates.
- Offer operators an emergency kill switch that allows operators to isolate or put chargers into safe, local‑only mode when backend connectivity is suspicious.
These measures together make the attack surface far harder to abuse and limit the fallout if a single component is compromised.
Vendor response and disclosure posture — what to expect
CISA’s publication indicates responsible disclosure channels were used (the advisory names researchers and indicates private reporting), and it gives ePower time to issue patches or configuration guidance. In practice, vendors typically respond to CISA advisories with a coordinated timeline: emergency configuration guidance and hot‑fixes, followed by staged security updates and post‑release hardening guidance.
Operators should expect the following from ePower in short order (if not already provided):
- A formal vendor advisory detailing affected components and exact CVE identifiers.
- Hotfixes or configuration workarounds to close unauthenticated endpoints and enforce session tightening.
- A recommended upgrade path and instructions to rotate credentials and invalidate sessions.
- Indicators of compromise (IoCs) and recommended log checks for post‑incident detection.
Until vendor patches are confirmed installed, do not assume an absent exploit signal equals safety. Treat the advisory as
actionable risk and apply compensating mitigations immediately. Evidence from industry feeds shows CVE records are being generated (some CVE numbers like CVE‑2026‑27770 are already listed in tracking feeds), but authoritative, fully populated NVD entries may lag initial reports; this is common practice and is why early mitigation based on the advisory text is essential.
Operational and systemic risks — beyond a single vendor
A compromised charging‑management platform is more than a convenience outage. The risks cascade:
- Customer safety and reputation: If chargers are remotely disabled or misconfigured, drivers may be stranded or harmed (for example, if charging stops mid‑session). Site hosts face reputational and contractual exposure.
- Billing and fraud: Unauthorized charge sessions or manipulated telemetry can create billing disputes and financial fraud at scale.
- Grid impacts: Mass disabling of chargers during peak demand, or orchestrated simultaneous charging to spike load unexpectedly, could stress local distribution equipment and complicate grid management, particularly where fleets or motorway clusters are affected.
- Insider lateral movement: Harvested operator credentials often provide entry to corporate IT networks, increasing the chance of ransomware or data‑exfiltration that can further devastate operator response.
For these reasons, the energy and transportation sectors treat vulnerabilgement as part of the critical infrastructure risk matrix; CISA’s advisory specifically frames the issue within energy and transportation sectors to emphasize this systemic scale.
What defenders should monitor now
- Unusual counts of failed authentications or login attempts on management portals.
- New or unexpected WebSocket connections that identify as chargers not in inventory.
- Remote Start/Stop commands issued outside scheduled maintenance windows.
- Changes to firmware versions or charger registration from unexpected IP addresses.
- Repeated token refresh requests and long lived tokens being reused across devices.
If any of the above are observed, treat them as high priority: isolate affected systems, rotate credentials, and preserve logs for forensic analysis. Report confirmed or suspected incidents to appropriate national authorities and CISA for correlation.
Closing analysis — strengths, weaknesses, and the road ahead
CISA’s advisory on ePower exposes a familiar truth in modern OT: convenience and interoperability (fast WebSocket connections, lightweight auth for devices) often come at the cost of rigor in authentication and session management. The strengths of the ePower platform — rapid installer onboarding, remote management, and broad site coverage — have enabled useful public charging services. But those same design choices, if not paired with industry‑grade secuhigh leverage for attackers.
Notable strengths of the public discussion and disclosure process so far:
- The advisory follows responsible disclosure, giving vendors a runway to patch while notifying operators of urgent mitigations.
- The content of the advisory is actionable: it provides categories and recommended immediate defensive steps operators can implement without waiting for patches.
Key risks and open questions:
- Some CVE records associated with the advisory are still being populated in public databases; this incomplete public record can slow defensive automation and scanning. Treat early CVE entries as provisional and rely on the adcriptions for immediate action.
- Vendor patch timelines and coordination details are crucial. Operators must not assume that a vendor‑provided configuration workaround is sufficient; insist on verifiable fixes and check post‑deployment logs.
Ultimately, this advisory should be a call to harden the operational chain: vendors must bake authenticated, audited device identity into their products; site hosts and operators must assume internet‑facing endpoints are exploitable until proven otherwise; and the wider energy and mobility ecosystem must treat charging management platforms as critical infrastructure and defend them accordingly.
In the immediate term: treat the March 3, 2026 advisory as effectively actionable. Inventory exposure, isolate control networks, enable MFA and rate‑limiting where possible, shorten session lifetimes, rotate secrets, and demand patch timelines from the vendor. The cost of inaction is not just interrupted service — it’s the potential to weaponize an essential public‑facing energy service in ways that ripple across customers, operators, and the grid.
Source: CISA
ePower epower.ie | CISA