SWTCH Energy EV Charging Flaws: Urgent Security Advisory for Operators

  • Thread Author
A coordinated set of high‑severity flaws in SWTCH Energy’s public-facing EV charging software has been flagged by U.S. federal cyber authorities, and the implications are wide enough to demand immediate action from operators, property managers, network defenders, and vendors that rely on SWTCH’s platform for charging management. The advisory identifies four CVE entries affecting SWTCH’s cloud and station-management surfaces and describes attack paths that allow unauthenticated control, session hijacking, credential exposure, large‑scale denial of service, and manipulation of telemetry and billing data — risks that map directly to both transportation and energy sectors.

Cybersecurity illustration of unauthorized access, session hijack, and credential exposure on a network.Background / Overview​

SWTCH Energy (branded SWTCH or SWITCH EV in some advisories) supplies software and cloud services used to manage EV chargers at multifamily and commercial properties. Operators use its management console and APIs to register chargers, authenticate sessions, orchestrate charge schedules, and report telemetry back to billing and energy‑management systems. On February 26, 2026, an Industrial Control Systems advisory was published calling out a cluster of authentication and session‑management weaknesses in SWTCH’s platform; the advisory lists CVE‑2026‑27767, CVE‑2026‑25113, CVE‑2026‑25778, and CVE‑2026‑27773 and assigns a high overall severity (CVSS vendor score v3: 9.4) for the affected equipment.
The vulnerabilities fall into four functional categories that are all about identity and session control:
  • Missing Authentication for Critical Function — endpoints that should require valid credentials are exposed or perform sensitive operations without verifying the caller.
  • Improper Restriction of Excessive Authentication Attempts — authentication endpoints lack protections against brute force or credential stuffing.
  • Insufficient Session Expiration — session tokens or authenticated sessions remain valid for longer than they should, enabling replay or hijacking.
  • Insufficiently Protected Credentials — credentials or secrets are stored, transferred, or handled in ways that make them discoverable or replayable.
Federal guidance recommends rapid defensive measures: reduce internet exposure of control systems, place devices behind firewalls, use segmentation, and harden remote access (for example, VPNs with modern configurations). The advisory credits researchers Khaled Sarieddine and Mohammad Ali Sayed for reporting the issues.

What exactly was reported: the technical picture​

The affected surface​

The vulnerabilities are tied to SWTCH’s public‑facing domain and product suite — the elements of the system that external chargers, management consoles, and third‑party integrations touch. In practice, that includes:
  • Charger registration and provisioning APIs
  • Station‑to‑cloud and cloud‑to‑station session management
  • Authentication and credential stores used by station agents and management consoles
  • Web or API endpoints that perform device commands or manage sessions
These are high‑value targets: compromise of these surfaces lets an attacker impersonate physical chargers, issue commands, or interfere with the telemetry and control plane used by operators to manage fleets.

Key weakness classes and practical consequences​

Each weakness maps to practical attacker capabilities:
  • Missing authentication for critical functions: If an API accepts unauthenticated requests for actions that should be restricted (for example, registering a charger, accepting meter values, or setting charge schedules), an attacker can impersonate chargers or administrative users. That enables fraudulent reporting (meter manipulation), unauthorized control (start/stop charge, set high current), or pivoting to other backend resources.
  • No or weak rate‑limit / lockout on authentication attempts: Without throttling or lockout, attackers can brute‑force credentials, crack administrative accounts, or enumerate valid accounts. This significantly lowers the bar for gaining privileged access.
  • Long‑lived sessions or tokens with little expiry: Persistent tokens let attackers reuse stolen session tokens or hijack active operator sessions for extended periods. Even if the original authentication vector is closed, a valid long‑lived token still grants access.
  • Credentials stored or transmitted insecurely: Cleartext or weakly protected credentials in configurations or logs make it trivial to harvest operator or device secrets. An attacker who obtains these can impersonate devices or administrators, and that access often leaves few immediate traces.
The advisory’s summary lists realistic attack outcomes: charger impersonation, session hijack, suppressed or misrouted traffic (enabling broad denial of service), and manipulation of data sent to the backend (metering/billing and telemetry). Those outcomes are not theoretical — they directly impact billing integrity, driver safety, service availability, and grid signals used for demand management.

Attack scenarios operators must treat as realistic​

Below are representative, pragmatic attack sequences that arise from the weakness classes above. Treat these as “playbook entries” that defenders should use in threat modelling, detection, and tabletop exercises.
  • Charger impersonation and billing fraud
  • Attacker registers a fake charger using an unauthenticated provisioning endpoint (or reuses harvested credentials).
  • The fake charger reports fabricated meter values and session logs to the SWTCH backend.
  • Billing systems accept the metering feed, enabling financial fraud or inaccurate usage records.
  • Session hijack and operational takeover
  • Attacker obtains a long‑lived session token (via theft, XSS on leasing console, or weak session invalidation).
  • Attacker uses the session to push new charge schedules, disable chargers, or set unsafe charging parameters.
  • Result: localized outage, damaged infrastructure, or unexpected load on the local distribution network.
  • Mass denial of service (supply‑chain style)
  • Attacker impersonates many chargers or issues commands en masse because authentication lacks rate limits.
  • The operator’s backend is flooded with bogus telemetry and command traffic, causing throttling, queuing, or complete service interruptions — drivers lose charging access en masse.
  • Credential replay and lateral movement
  • Credentials or tokens left in logs or firmware snapshots are extracted.
  • Attacker reuses them to access other services (analytics, firmware update servers), potentially obtaining code signing keys or firmware images.
These scenarios illustrate why the advisory treats these weaknesses as critical for both Energy and Transportation sectors: EV charging infrastructure sits at the intersection of grid load control and mobility services.

Who and what is at risk​

  • Property managers and building operators that place charging stations on their sites and rely on SWTCH’s cloud for orchestration are directly exposed. Impact ranges from denied charging access for tenants to unexpected energy bills.
  • EV drivers can face safety risks and service disruption if charging sessions are manipulated or chargers are forced into unsafe states.
  • Utility and grid operators may see distorted demand signals — charging orchestration systems participate in load balancing and demand response. Manipulated telemetry undermines grid management and can trigger suboptimal or unstable responses.
  • Service integrators and third‑party platforms that federate charger fleets using SWTCH APIs risk credential exposure and supply‑chain cascades.
Given worldwide deployment of chargers and the central role of some charging platforms in building EV ecosystems, the blast radius for authentication/session failures is significant.

Vendor posture and public reporting​

SWTCH’s own public security and product pages emphasize device and site hardening features such as AI‑driven vandalism detection and device monitoring. The advisory indicates the vendor was notified and credited researchers who reported the issues. At the time of the advisory’s publication, the federal notice records “no known public exploitation” specifically tied to these CVEs. That is not an assurance that exploitation isn’t happening — it is simply what has been reported to the agency.
Operators should assume that once issues are publicized at the CVE or advisory level, opportunistic scanning and attempted abuse will follow quickly. This is a common pattern observed in similar ICS and IoT advisories: public disclosure accelerates attacker scanning and exploitation attempts.

Immediate action checklist (priority triage)​

If you operate SWTCH‑managed chargers or rely on SWTCH services, act now. Prioritize actions in the order below; each step provides immediate risk reduction.
  • Identify affected assets
  • Inventory all SWTCH‑connected chargers, gateway devices, and management consoles.
  • Record whether each device has direct internet exposure or is reachable only via vendor tunnels.
  • Minimize internet exposure
  • Block or restrict external access to charger management interfaces.
  • Place management interfaces and device provisioning endpoints behind firewalls and access control lists.
  • Apply vendor fixes
  • Check SWTCH vendor channels and apply any patched releases or configuration changes the vendor provides.
  • If no patch is available, implement the compensating controls below.
  • Harden authentication
  • Enforce multi‑factor authentication for all operator accounts.
  • Rotate credentials and secrets immediately. Invalidate long‑lived sessions and force reauthentication.
  • Implement rate limiting and account lockout for failed authentication attempts.
  • Segment networks
  • Move chargers and EVSE management functions into a segmented network zone with strict egress rules.
  • Prevent direct lateral movement from charger networks to corporate networks or critical infrastructure.
  • Monitor and log
  • Enable and centralize detailed authentication and provisioning logs.
  • Look for anomalous patterns: many provisioning attempts from single IPs, sudden flurries of meter submissions, or unknown device IDs appearing in management console.
  • Audit stored secrets
  • Inspect any device configuration backup, firmware bundles, or logs for plaintext credentials or keys.
  • Remove or rotate any exposed secrets.
  • Communicate
  • Notify internal incident response and property stakeholders.
  • If you observe suspicious activity, follow the advisory guidance and report to appropriate national/sector CERTs or CISA.

Recommended technical mitigations (medium and long term)​

Beyond emergency triage, these are engineering changes operators and vendors should adopt to eliminate the underlying classes of risk:
  • Implement mutual TLS and per‑device PKI for charger‑to‑cloud authentication so chargers prove their identity with unique device certificates and keys.
  • Use a secure hardware root-of-trust and signed firmware to prevent kernel/agent manipulation on chargers and gateways.
  • Enforce short session lifetimes and immediate token revocation on sensitive changes; pair this with secure refresh token flows.
  • Rate‑limit authentication endpoints and introduce progressive backoff and lockout after failed attempts.
  • Store secrets in hardened vaults (HSM or cloud KMS) — never in logs, firmware, or plain configuration files.
  • Implement robust logging, tamper‑evident audit trails, and continuous telemetry validation to detect fake meter or session data.
  • Adopt signed and versioned APIs with strict schema validation to reject malformed or spoofed provisioning requests.
  • Integrate anomaly detection models that can flag sudden bursts of new device registrations or inconsistent meter feeds.
These architectural controls are consistent with modern ICS security guidance and EV‑domain recommendations emerging from research into protocol‑level threats (for example, work that demonstrates physical and protocol‑layer injection and MitM possibilities in EV charging standards).

Operational detection guidance: indicators defenders should hunt for​

  • Unexpected or massed charger registration events originating from small sets of IPs.
  • Rapid authentication failures followed by a successful login from the same source.
  • New device IDs that report implausible meter values (extremely high or negative energies).
  • Long‑lived tokens used well outside normal working hours or from unusual geolocations.
  • Sudden spikes of provisioning or telemetry traffic that saturate backend queues.
  • Changes to charge profiles issued outside scheduled maintenance windows.
Hunting for these patterns in SIEM and centralized logs should be high priority. Where possible, use behavior baselining so deviations from normal fleet behaviour produce high‑signal alerts.

Governance, supply chain, and contractual safeguards​

Security of EV charging is as much a governance and procurement issue as it is a technical one. Property operators and integrators should:
  • Require vendors to demonstrate secure development practices, vulnerability disclosure programs, and patch timelines before procurement.
  • Include contractual clauses requiring timely patching of critical issues and notifications of security incidents.
  • Insist on per‑device unique credentials and attestations, not shared secrets across fleets.
  • Budget for periodic third‑party security assessments and red‑team exercises focused on charger registration, provisioning, and API endpoints.
Given the key role charging systems play in grid management and mobility, regulators and utilities may increasingly require these controls as minimum standards.

Broader implications for EV infrastructure security​

The SWTCH advisory is the latest in a pattern: researchers and red teams have repeatedly shown how EV charging protocols and physical‑layer interfaces can be manipulated. Recent academic work has demonstrated wireless MitM and signal‑injection attacks against charging protocols, while other advisories have flagged insecure firmware, cleartext secrets, and control interface exposure across charger vendors.
Two systemic lessons stand out:
  • Identity is everything. The most damaging attacks cross identity boundaries — where a device claims to be a legitimate charger or an administrator session is accepted without sufficient verification. Strong per‑device identity and mutual authentication are non‑negotiable.
  • Operational visibility and segmentation reduce impact. Even when a vendor or manufacturer fixes a bug, operators who lack asset visibility or have flat networks will still suffer wide blast radii. Defense in depth — segmentation, hardened perimeters, and robust monitoring — reduces the window of exploitation and the scale of potential impact.
From a policy and utility standpoint, compromised charging management platforms can distort load forecasts, costing utilities and end customers money and increasing the risk of brownouts in stressed distribution networks. From a consumer standpoint, compromised billing or safety can erode trust in the EV ecosystem.

What defenders should say to stakeholders (quick messaging templates)​

  • To building/property leadership: “We have a critical advisory concerning our charging‑management vendor; we’ve immediately restricted external access to charger management endpoints, rotated credentials, and begun validation of all active sessions. We are following vendor guidance and will update you as we complete patching.”
  • To operations teams: “Treat any unexpected meter reports or device registrations as suspicious. Enable high‑verbosity logging and forward logs to incident response. Do not reboot or reset devices without coordination — collect forensic data first.”
  • To drivers and tenants: “There is no confirmed public exploitation affecting our site at this time, but we are taking proactive steps to secure chargers and prevent interruptions.”
Clear, accurate, and calm communication prevents panic and preserves trust while defenses are being enacted.

Final assessment: risk vs. urgency​

The combination of vulnerability classes reported in this advisory produces a high risk profile: flaws that allow unauthenticated privileged actions combined with weak session controls and exposed credentials are the kind that enable both targeted takeovers and mass automated abuse. The industry has seen rapid exploitation follow public disclosures in the past; while the advisory states no known public exploitation was reported at publication, operators must treat that as a narrow snapshot rather than a guarantee.
For operators, the urgency is high: immediately triage and implement the emergency checklist above. For vendors and platform providers, the obligation is to patch quickly, disclose transparently, and build stronger identity, token, and credential hygiene into their platforms.
Finally, for the broader EV and grid community, this advisory is a reminder that EV charging is not merely a convenience layer — it is critical infrastructure that requires the same rigorous security lifecycle management we demand of traditional operational technology: unique device identity, signed firmware, short session lifetimes, robust telemetry validation, and defense‑in‑depth network architectures. Only with those pieces in place can the charging ecosystem scale securely without creating systemic risks to mobility and to the grid.

Source: CISA SWITCH EV swtchenergy.com | CISA
 

Back
Top