Vulnerabilities

Monta EV chargers can be impersonated, CVSS 9.4

By Yaali. October 4, 2026, 6 min read, Vulnerabilities, Resilience.

CISA lists four flaws in every version of Monta's EV charging platform. Anyone who knows a station ID can pose as the charger. Here is what to change.

CISA published advisory ICSA-26-274-02 on October 1, 2026, covering four vulnerabilities in monta.app, the cloud platform Monta uses to run electric vehicle chargers for site hosts, fleets and charge point operators. All versions are listed as affected. The worst, CVE-2026-95102 (CVSS 9.4), is missing authentication on the WebSocket endpoints that chargers connect to, so anyone who knows a station's identifier can connect and pretend to be that charger. CISA lists the energy and transportation sectors, worldwide.

Closing the main hole takes a configuration change on each charger, and until that change is made, the station ID is the only thing standing between an attacker and your charger's backend connection. CISA says no exploitation has been reported. If you host chargers that report to Monta, whether at an office car park, a depot or a public site, this affects you, and the work falls on whoever configured those chargers.

How OCPP works

OCPP (Open Charge Point Protocol) is the open standard, maintained by the Open Charge Alliance, that lets a charger talk to a central management system from any vendor. In OCPP 1.6J, the version Monta's charger integration guides use, the charger opens a WebSocket (a long-lived two-way connection over HTTP) to the backend and keeps it open. The charger identifies itself by appending its identity to the URL path, for example wss://backend.example.com/ocpp/CP001. The messages themselves do not repeat it, so whatever connected on that path is treated as that charger.

Over that socket the charger reports to the backend: BootNotification with its vendor, model and firmware on start-up, StatusNotification when a connector becomes available or faulted, Authorize to check an RFID card, StartTransaction and StopTransaction around each session, and MeterValues with energy readings. The backend sends commands the other way: RemoteStartTransaction, Reset, ChangeConfiguration to write a setting, and UpdateFirmware with a URL to download from.

Authentication came to OCPP 1.6 later, through three security profiles. Profile 1 is HTTP Basic authentication over an unencrypted connection, suitable only inside a private network or VPN. Profile 2 adds TLS, so the charger checks the backend's server certificate and then sends a username and password inside the encrypted channel. Profile 3 uses TLS client certificates on both sides. None of them is on by default; each has to be configured on the charger and the backend.

How the impersonation works

CVE-2026-95102 (CWE-306, missing authentication for a critical function) means Monta's OCPP endpoint accepted a charger connection on the strength of the identity in the URL alone. The CVSS vector needs no privileges and no user interaction. CISA says exploitation could let an attacker impersonate stations and access sensitive data.

The identity is not secret. CVE-2026-93474 (CVSS 6.5) records that station authentication identifiers are publicly visible on web-based mapping platforms, the charger maps drivers use to find a plug.

An attacker with a WebSocket client can therefore connect as a real charger. They could then send false status and meter readings, which feed billing and availability, and receive commands and data meant for the real station. CISA's summary is that successful exploitation could give unauthorized administrative control over vulnerable charging stations or disrupt charging through denial of service.

Two further flaws make this worse. CVE-2026-97363 (CVSS 7.5) is no limit on authentication attempts at the WebSocket API, which allows brute forcing and denial of service by flooding connections. CVE-2026-97212 (CVSS 7.3) lets several endpoints connect with the same session identifier, which CISA says are predictable. When two sockets claim one charger, the backend has to choose one. If the impostor wins, the real charger loses its connection to its own backend, and doing that to many stations at once is an outage.

Other charging backends had the same flaw this year. CISA advisories for ev.energy (ICSA-26-057-07, February 26) and EVoke Systems (ICSA-26-176-02) describe the same missing OCPP WebSocket authentication with the same 9.4 score. Check any backend you use, not only Monta.

What Monta has said

According to the CISA advisory, Monta reported three measures:

• It supports OCPP 1.6 Security Profile 2 (HTTP Basic Auth with TLS), encourages operators to enable it, and is working to increase adoption of authenticated connections and to deprecate unauthenticated access on a rolling basis.
• It has added rate limiting and automated connection throttling at the WebSocket layer to block rapid reconnection and ID brute forcing.
• It handles duplicate connection attempts per the OCPP specification, where a new authenticated connection supersedes an existing session.

The advisory gives no date for when unauthenticated connections will stop being accepted, and lists no fixed version.

What to do

Site hosts and fleet operators rarely set OCPP options themselves; an installer or charge point operator did. Ask them for these steps, in order.

1. List every charger connected to Monta. For each one record model, firmware version, the OCPP URL it uses and which security profile it is set to. Ask the charger vendor whether that firmware supports Security Profile 2 over OCPP 1.6J.
2. Turn on Security Profile 2 with a unique password per station. The URL must start with wss:// (TLS), not ws://, and each charger needs its own long random password that has nothing to do with its station ID or serial number. Set it through the charger's own configuration tool or, where the charger allows, with ChangeConfiguration on the AuthorizationKey key, and register the same password on the Monta side.
3. Store the passwords in a password manager or vault. Keep them off the installation sheet, and plan how to rotate them when an installer leaves.
4. For chargers that cannot do Profile 2, ask the vendor for a firmware update and put replacements on the budget. If a site can keep chargers on a private APN or VPN to the backend, that limits who can reach the connection meanwhile.
5. Look for signs of misuse. Ask Monta or your operator for connection logs per charger and check for chargers that dropped offline and reconnected repeatedly, two connections for one station ID, connections from IP addresses outside your chargers' mobile carrier or site network, and status or meter readings that do not match what the site saw. Compare billed energy with the site's own meter.
6. Plan for an outage. CISA rates the denial of service flaws high. Decide in advance what a fleet depot does if chargers stop accepting sessions overnight, and check that chargers can fall back to local authorization lists so vehicles still charge.

Longer term, Security Profile 3 or OCPP 2.0.1 removes the shared password, where firmware and certificate management allow it.

The wider lesson

Chargers are bought as electrical equipment, and their network connection is often set once by an installer and never revisited. Here a device identifier printed on a public map was doing the job of a password. Ask the same question of any equipment that reports to a vendor cloud, solar inverters included: what proves to the cloud that this device is really ours?

Our attack surface management work maps connected devices like chargers and the services they talk to, and our network penetration tests check whether those connections can be spoofed or reached from where they should not be. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

Sources: CISA ICS advisory ICSA-26-274-02, SecurityOnline, DEV Community analysis, Strix CVE-2026-95102 detail, Assurant Cyber summary, CISA ICSA-26-057-07, CISA ICSA-26-176-02, OCPP security profiles explained, OCPP 1.6J reference.