CISA has published an industrial-control-systems advisory (ICSA-26-057-08) that calls out a cluster of high‑severity authentication and session‑management flaws in Mobility46’s public-facing charging‑station software (mobility46.se), warning that successful exploitation could let attackers gain administrative control of chargers or disrupt charging services through denial‑of‑service actions. rview
Mobility46 is named in the advisory as a provider of charging‑station management software used across energy and transportation sectors worldwide, with headquarters in Sweden. The advisory lists four tracked vulnerabilities (CVE‑2026‑27028, CVE‑2026‑26305, CVE‑2026‑27647, CVE‑2026‑22878) and assigns a vendor CVSS v3 score cluster that reaches up to 9.4, indicating critical impact when chained or weaponized against exposed systems. The reported weaknesses fall into familiar web/identity failure classes: Missing Authentication for Critical Function, Improper Restriction of Excessive Authentication Attempts (brute‑force), Insufficient Session Expiration, and Insufficiently Protected Credentials — categories that routinely enable account takeover, session replay, and credential theft in both IT and OT environments.
Those CWE categorie in secure‑development and ICS communities: missing authentication for a critical function allows an unauthenticated attacker to perform actions intended only for privileged users; insufficient session expiration and weak session controls enable long‑lived tokens to be reused or replayed; and poorly protected credentials (cleartext storage, weak hashing) make offline cracking or credential reuse trivial. These failure modes are documented and mapped in common weakness taxonomies and web application guidance.
Why this matters: EV charging infrastructure straddles IT and physical operational technology. A remotely exploitable administrative path or a reliable denial‑of‑service vector doesn’t just inconvenience drivers — it creates grid‑load, billing, and safety risks across transport and energy systems. CISA’s advisory explicitly places Mobility46’s affected products into the Energy and Transportation Systems critical‑infrastructure sectors and emphasizes worldwide deployment, meaning operators — from site owners to parko utilities — must treat this advisory as a priority for immediate risk triage.
Breaking down the classes named in the advisory gives us a practical threat model.
Two key transparency expectations vendors should meet:
CISA’s advisory model encourages vendors and researchers to coordinate; that coordination must produce actionable artifacts (patches, reproduction steps limited to defenders) and clear timelines. Where those are absent, the operational burden falls on administrat window of opportunity for attackers.
Where specific exploit PoCs or public exploitation have not been reported, assume opportunistic scanning and targeted credential stuffing are immediate threats — historically these are the fastest, simplest routes to compromise for authentication/session bugs. Apply compensating controls accordingly.
Operators should immediately triage network exposure, rotate credentials, enforce MFA, and implement monitoring rules to detect credential‑stuffing or token replay. Vendors must publish clear patching guidance and harden their authentication and session handling in subsequent releases. The broader security community — utilities, site operators, and regulators — should treat this advisory as a call to strengthen both technical controls and supply‑chain transparency across the EV charging ecosystem.
If you manage Mobility46‑based chargers: assume exposure is an operational emergency and execute the prioritized action list above today. Defensive measures that reduce Internet exposure and enforce strong authentication will substantially reduce your attawait vendor patches.
Source: CISA Mobility46 mobility46.se | CISA
Mobility46 is named in the advisory as a provider of charging‑station management software used across energy and transportation sectors worldwide, with headquarters in Sweden. The advisory lists four tracked vulnerabilities (CVE‑2026‑27028, CVE‑2026‑26305, CVE‑2026‑27647, CVE‑2026‑22878) and assigns a vendor CVSS v3 score cluster that reaches up to 9.4, indicating critical impact when chained or weaponized against exposed systems. The reported weaknesses fall into familiar web/identity failure classes: Missing Authentication for Critical Function, Improper Restriction of Excessive Authentication Attempts (brute‑force), Insufficient Session Expiration, and Insufficiently Protected Credentials — categories that routinely enable account takeover, session replay, and credential theft in both IT and OT environments.
Those CWE categorie in secure‑development and ICS communities: missing authentication for a critical function allows an unauthenticated attacker to perform actions intended only for privileged users; insufficient session expiration and weak session controls enable long‑lived tokens to be reused or replayed; and poorly protected credentials (cleartext storage, weak hashing) make offline cracking or credential reuse trivial. These failure modes are documented and mapped in common weakness taxonomies and web application guidance.
Why this matters: EV charging infrastructure straddles IT and physical operational technology. A remotely exploitable administrative path or a reliable denial‑of‑service vector doesn’t just inconvenience drivers — it creates grid‑load, billing, and safety risks across transport and energy systems. CISA’s advisory explicitly places Mobility46’s affected products into the Energy and Transportation Systems critical‑infrastructure sectors and emphasizes worldwide deployment, meaning operators — from site owners to parko utilities — must treat this advisory as a priority for immediate risk triage.
What the vulnerabilities actually allow — technical analysis
Breaking down the classes named in the advisory gives us a practical threat model.Missing Authentication for Critical Function (CWE‑306)
- What it means: Administrative or control APIs do not require valid credentials or allow unauthenticated access to commands that change configuration, add payment endpoints, or toggle charger state.
- Consequence: An unauthenticated actor could perform high‑impact actions — create or use admin accounts, change firmware settings, or issue immediate stop/start commands to chargers. In an OT context, that can translate to unexpected power draw, billing errors, or cascaded operational failures.
Improper Restriction of Excessive Authentication Attempts (CWE‑307)
- What it means: No effective rate limits, IP lockouts, or adaptive throttling on authentication endpoints.
- Consequence: Attackers can perform large‑scale brute‑force or credential‑stuffing campaigns to discover valid admin credentials. When combined with leaked password lists or reused enterprise passwords, this accelerates takeover risk.
Insufficient Session Expiration (CWE‑613)
- What it means: Sessions or tokens last much longer than they should, or session revocation is unreliable.
- Consequence: Session‑replay and lateral use of stale tokens become practical: a captured session token (from logs, backups, or memory scraping) may grant persistent access even after the user logs out or rotates credentials.
Insufficiently Protected Credentials (various CWEs)
- What it means: Credentials are stored with weak hashing, in cleartext configuration files, or embedded in firmware images.
- Consequence: Once an attacker reads a file or intercepts a backup, they can recover credentials offline — undermining all perimeter controls.
Realistic attack scenarios and consequences
The following attack chains are both realistic and immediate for administrators to model:- Credential stuffing → admin access
- An attacker uses breached corporate credentials or common passwords against Mobility46’s admin endpoints (no rate limits). Once a valid admin login is found, they alter station configuration, add remote management accounts, or deploy malicious firmware pointers.
- Session replay and lateral control
- Using insufficient session expiration, an attacker replay‑uses a captured token to issue administrative commands, even after the legitimate operator logged out. This can be used to pivot to other chargers managed by the same backend.
- Denial‑of‑service against charging services
- Exploiting an unauthenticated control function or weak auth, an attacker triggers repeated start/stop cycles or floods management endpoints to exhaust CPU/memory, knocking out charging at scale.
- Billing and metering manipulation
- With administrative control, attackers can alter pricing, meter readings, or authorization rules — causing revenue loss, fraudulent charging, and erroneous grid draw calculations.
- Physical‑safety risks
- While most chargers implement local safety interlocks, remote commands that override proper sequencing or that force repeated resets can degrade equipment and, in a worst case, increase arc or wear risks — especially when combined with physical tampering.
Who should care, and what to check first
- Site operators and charge‑point owners — prioritize immediate network isolation and access controls for any devices running Mobility46 software.
- Managed service providers and utilities — assess whether Mobility46‑managed stations are bridged to billing, grid management, or DER orchestration layers; if so, escalate to incident response.
- Security operations teams — look for signs of credential stuffing, anomalous admin API calls, and repeated authentication failures in logs.
- OEMs and installers — confirm whether installed firmware stacks embed Mobility46 components and schedule emergency patches or mitigations.
- Confirm whether any Mobility46 endpoints are reachable from the public Internet.
- If publicly reachable, restrict access via firewall rules or move to a private management VLAN.
- Force a credential rotation for admin accounts and remove legacy or shared credentials.
- Enable or enforce MFA for any remote management or operator accounts where support exists.
- Monitor logs for repeated failed authentication attempts and for unknown long‑lived sessions.
Immediate mitigations while you wait for vendor patches
Until Mobility46 releases and you apply vendor‑provided patches or configuration updates, apply layered mitigations:- Network level
- Remove public‑Internet exposure for management interfaces; place them behind a firewall and VPN with MFA.
- Use access‑control lists to permit only trusted management subnets or jump servers to talk to chargers.
- Implement Out‑of‑Band (OoB) management for critical control paths so operational traffic is isolated from corporate networks.
- Authentication & sessions
- Enforce password rotation and eliminate default/shared accounts.
- Introduce or enforce MFA for administrative accounts.
- Shorten session timeouts on all management consoles and APIs.
- Apply rate limiting and IP‑based throttling at the perimeter to mitigate brute‑force attempts.
- Credential storage & secrets
- Audit all configuration files and firmware packages for embedded credentials; replace or remove them.
- Where possible, transition to hardware‑protected keys or centralized secret stores with strict access auditing.
- Detection & response
- Enable detailed authentication logging and forward to a SIEM or log collector.
- Create alarms for:
- multiple failed login attempts from a single IP
- admin actions originating from unexpected geo‑locations
- long‑lived session tokens used after logout
- Run forensic checks if anomalous activity is observed: check scheduled tasks, unusual processes, and firmware changes.
- Safety controls
- Ensure local, physical safety interlocks remain independent of remote management paths.
- Where possible, instruct site operators to prepare manual service procedures for charger shutdown and restart.
Detection tips — what to look for in logs and telemetry
Operators should hunt for the following high‑signal indicators of compromise:- Repeated authentication attempts (high failure rate) from small sets of IPs or from many different IPs consistent with credential‑stuffing.
- Administration API calls that change configuration (create admin accounts, change firmware URLs, change payment endpoints) originating from non‑operator IPs.
- Long session tokens used after a user explicitly logs out.
- Presence of unexpected or unrecognized administrator users; look for privilege escalation activity.
- Unusual patterns of charger state changes (start/stop cycles) outside normal operating windows.
- Unauthorized changes to meter or billing records.
Vendor coordination and disclosure responsibilities — a critical look
Coordinated disclosure is still the best path: vendors should publish precise affected versions, CVE records, and clear remediation steps. The advisory lists Mobility46 versions as “vers: all” and enumerates four CVEs; however, public CVE/NVD records or vendor advisories may lag behind the advisory author in indexing and detail. Operators must therefore treat the CISA advisory as an authoritative alert while also demanding a concrete patch timeline and vendor confirmation of affected builds.Two key transparency expectations vendors should meet:
- Publish fixed‑version identifiers and upgrade paths so operators can validate whether their instances are vulnerable.
- Provide out‑of‑band mitigation instructions (e.g., immediate configuration changes) for operators who cannot patch immediately.
CISA’s advisory model encourages vendors and researchers to coordinate; that coordination must produce actionable artifacts (patches, reproduction steps limited to defenders) and clear timelines. Where those are absent, the operational burden falls on administrat window of opportunity for attackers.
Longer‑term remediation: secure design and product hardening
To prevent similar issues from recurring, Mobility46 and other EV‑charging platform vendors should adopt and demonstrate the following engineering commitments:- Secure authentication and authorization by design
- Enforce least privilege, RBAC for administrative actions, and strong hashing of credentials (modern KDFs such as Argon2 or PBKDF2 with high iteration counts).
- Session management hygiene
- Implement short, revocable session tokens with refresh flows and secure cookie flags (HttpOnly, Secure, SameSite) and token binding where feasible.
- Brute‑force resistance
- Integrate backend rate limiting, account lockout policies, and progressive delays for repeated failed attempts.
- Secrets management
- Avoid embedding credentials in firmware or config; use a secure secret vault or hardware root of trust.
- Secure update mechanism
- Sign firmware and supply verification steps; provide atomic rollback and purge capabilities for compromised credentials.
- Transparent vulnerability lifecycle
- Maintain a public security advisory feed with fixed versions, patch notes, CVE mappings, and mitigation steps.
What operators should do this week — a prioritized action plan
- Inventory and exposure check
- Identify all Mobility46 instances and confirm whether management interfaces are Internet‑accessible.
- Network containment
- Block public access to management ports immediately; require management via VPN and restrict to operator IP ranges.
- Credentials and sessions
- Rotate all privileged credentials, enable MFA, and shorten session timeout values.
- Monitoring and alerting
- Turn on detailed authentication and admin‑action logging; set detectors for repeated auth failures and unusual admin activity.
- Vendor liaison
- Open a formal support/incident ticket with Mobility46; request their patch timeline and apply vendor mitigations as soon as they’re available.
- Reporting and coordination
- If you see suspicious activity, follow internal incident response procedures and report to national CSIRT or CISA channels as appropriate.
Limitations and caveats — what we could not independently verify
The advisory text and the list of CVE identifiers were provided in the initial notification; however, at the time of writing, some public vulnerability databases and vendor pages may not include fully indexed records or detailed vendor patch bulletins for each CVE. Readers should treat the CVE list reported in the advisory as authoritative but cross‑check with official vendor advisories and the national vulnerability database for complete remediation metadata. If you rely on third‑party patch automation, validate that your tools have the correct affected‑version ranges before applying broad updates.Where specific exploit PoCs or public exploitation have not been reported, assume opportunistic scanning and targeted credential stuffing are immediate threats — historically these are the fastest, simplest routes to compromise for authentication/session bugs. Apply compensating controls accordingly.
Conclusion — takeaways for operators and vendors
CISA’s advisory concerning Mobility46 (ICSA‑26‑057‑08) is a timely reminder that EV charging infrastructure is now a converged attack surface combining web application semantics with physical operational effects. The named vulnerabilities — authentication bypass types, session management failures, and weak credential protection — are classic, high‑impact defects that can be chained into administrative takeover or denial‑of‑service attacks.Operators should immediately triage network exposure, rotate credentials, enforce MFA, and implement monitoring rules to detect credential‑stuffing or token replay. Vendors must publish clear patching guidance and harden their authentication and session handling in subsequent releases. The broader security community — utilities, site operators, and regulators — should treat this advisory as a call to strengthen both technical controls and supply‑chain transparency across the EV charging ecosystem.
If you manage Mobility46‑based chargers: assume exposure is an operational emergency and execute the prioritized action list above today. Defensive measures that reduce Internet exposure and enforce strong authentication will substantially reduce your attawait vendor patches.
Source: CISA Mobility46 mobility46.se | CISA
