CISA republished ABB’s advisory for CVE-2025-5517 on May 26, 2026, warning that certain ABB Terra AC wallbox electric-vehicle chargers can be affected by a heap-based buffer overflow triggered through specially crafted OCPP messages sent via charger-management infrastructure. The flaw is rated medium, not because the impact is trivial, but because the attacker’s path is constrained. That distinction matters: the advisory is less a story about one charger bug than about how EV charging has quietly become operational technology at the edge of ordinary life.
The ABB Terra AC is not an exotic industrial controller hidden in a fenced substation. It is a Level 2 EV wallbox, the sort of device deployed in commercial garages, fleet depots, apartment buildings, workplaces, and residential installations. That makes this advisory unusually easy to underestimate.
The vulnerability sits in the charger’s handling of OCPP, the Open Charge Point Protocol used to connect charging stations to a Charging Station Management System. In plain English, OCPP is the conversation between the charger and the backend that tells it how to authenticate users, report status, receive configuration, and participate in a managed charging network.
That management channel is precisely what gives modern EV infrastructure its value. It also gives attackers a route into devices that used to be thought of as electrical equipment rather than networked computers with safety, billing, and availability implications.
ABB’s warning is direct: a specially crafted OCPP message could pollute heap memory, potentially allowing remote control of the product and writes to flash memory that alter firmware behavior. That is not merely a crash bug. It is the kind of memory-corruption flaw that forces operators to ask whether a device at the edge of their infrastructure can still be trusted after compromise.
A charger that lies about its state, stops charging vehicles, writes altered behavior to flash, or runs unpredictably can create operational headaches that look very different from classic data theft. In a fleet environment, unavailable chargers can mean vehicles are not ready. In a commercial site, unreliable chargers become support tickets, refunds, angry drivers, and a reputational problem. In a managed energy setting, devices that no longer obey expected behavior can undermine load balancing and demand-response plans.
This is the trap in reading industrial advisories like consumer app release notes. A medium score on a spreadsheet may still describe a vulnerability that matters deeply to the people who own the process, the parking facility, the service contract, or the fleet schedule.
ABB also says it had not received reports of exploitation when the advisory was issued, and that the vulnerability had not been publicly disclosed at that time. That lowers the immediate temperature. It does not eliminate the obligation to patch, especially now that the affected versions, fixed versions, and exploit conditions are public.
In many organizations, the charger is treated as a peripheral. The backend is treated as a vendor portal. The network path between them is treated as plumbing. CVE-2025-5517 is a reminder that all three are part of the same trust boundary.
If the CSMS can send commands to the charger, then compromise of the CSMS or its communications path can become compromise of the charger. If the charger accepts malformed management messages badly enough to corrupt heap memory, then the backend channel becomes a delivery mechanism for code execution, denial of service, or firmware-level mischief.
The advisory’s emphasis on TLS is not boilerplate. OCPP has historically allowed deployments over plain HTTP, and vendors have had to support real-world installations where convenience outran security architecture. That may have been tolerable when chargers were isolated gadgets. It is harder to defend when chargers are managed, metered, integrated into business workflows, and deployed in numbers.
That variation is not unusual in embedded products, but it is precisely why asset inventory matters. “We have ABB Terra AC chargers” is not enough information. Operators need the exact model line, regional variant, and firmware version, because the safe endpoint differs across the family.
The advisory also contains a small but important wrinkle: some versions identified in the CISA republication as affected overlap with version numbers also named in the remediation text for certain variants. That is the kind of detail that can happen when vendor CSAF data, product variants, and republication pipelines meet the messy reality of firmware branches. For operators, the answer is not to guess from a headline but to verify against ABB’s product-specific update path and management tooling.
The practical priority is simple: identify Terra AC units, determine the variant, confirm firmware, and move to the fixed release for that variant. If a charger is remotely managed by a third-party CSMS provider, the site owner still needs confirmation that the device firmware and backend transport are secure. Outsourcing the portal does not outsource the risk.
But open protocols do not make insecure deployments safe. They make assumptions visible.
The ABB advisory describes exploitation through a specially crafted OCPP message sent either by a compromised backend or over an unsafe communications path. That is a familiar pattern in industrial and IoT security: the device trusts its management plane, the management plane is exposed or insufficiently hardened, and a protocol feature becomes the attack surface.
The cure is not to abandon OCPP. It is to treat it like a privileged administrative channel. That means TLS by default, certificate validation, backend hardening, monitoring for abnormal command patterns, and segmentation that prevents charger networks from becoming a flat extension of the corporate LAN.
For WindowsForum readers, the analogy is obvious. You would not expose WinRM, RDP, or a domain controller management path casually and then blame Windows when administrative traffic becomes the attack vector. EV chargers deserve the same mental model. They are managed endpoints, and their management channel is privileged.
That is especially relevant in parking structures, campuses, retail sites, and mixed-use developments where network ownership can be fragmented. The facilities team may own the charger. A contractor may have installed it. A managed-service provider may run the backend. The network team may not know precisely what VLAN it is on. The building owner may assume the vendor has handled security.
This is how edge infrastructure becomes vulnerable: not because nobody cares, but because everybody thinks somebody else owns the boundary.
The advisory’s mitigation section reads like standard ICS guidance because the lessons are standard. Minimize network exposure. Put control systems behind firewalls. Isolate operational networks from business networks. Use secure remote access. Perform impact analysis before applying defensive changes. None of that is glamorous, but glamorous security advice is rarely what keeps infrastructure running.
A workplace charger can be a perk. A depot charger can be mission-critical. A public charger can be part of transportation availability. The same vulnerability can therefore carry very different consequences depending on where the device is installed.
This is why the old consumer IoT framing falls short. A smart bulb going offline is annoying. A charger fleet misbehaving before a morning dispatch window is an operational incident. A managed charging system that can be manipulated may affect not only drivers but also billing, maintenance, utilization data, and electrical load planning.
The industry has been racing to deploy chargers, and reasonably so. Adoption pressure is real. But every charger added to a network is also a small Linux-or-RTOS-flavored computer with firmware, protocol parsers, certificates, logs, update mechanisms, and a vendor support lifecycle. The charging revolution is also an endpoint-management problem.
The advisory also says ABB had no known exploitation at the time of issue. That should be read as a point in favor of patching before urgency becomes panic. The best vulnerability response is boring: disclosure happens, fixed firmware appears, operators update, and the story ends without a breach.
Unfortunately, embedded-device patching is often the opposite of boring. Devices may be installed in places with weak connectivity. Owners may not have portal access. Firmware updates may require installer involvement. Some sites may be nervous about touching equipment that is currently working. A small number of failed updates can sour operators on the entire process.
That is why vendors need to make security updates predictable, reversible where possible, and clearly tied to model-specific release notes. It is also why owners need to treat charger maintenance as part of normal infrastructure operations, not as an exception triggered only when something breaks.
There is a networked endpoint. It runs firmware. It accepts remote management commands. It parses structured messages. It has a vendor update channel. It may sit on a segmented network, or it may not. It may use TLS properly, or it may have been deployed in a compatibility mode nobody revisited.
That sounds less like electrical infrastructure and more like a fleet of specialized appliances. Windows administrators have spent two decades learning that specialized appliances still need inventories, patch windows, credentials, certificates, logging, and owners. EV charging networks are now entering that same discipline.
This is also where Windows environments become relevant indirectly. Many charger-management workflows touch Windows desktops, browser portals, exported reports, helpdesk queues, identity providers, or corporate networks. A charger vulnerability may not target Windows, but the operational response will often run through Windows-managed organizations.
Organizations should assume there will be more charger vulnerabilities, not fewer. That is not cynicism; it is the normal path of a maturing technology. More deployments attract more researchers. More integrations create more parsing surfaces. More backend features create more privileged commands. More operational reliance raises the value of disruption.
The durable fix is defense in depth. Chargers should not be directly reachable from the open internet. Charger networks should be segmented. Backend credentials should be protected like administrative credentials. TLS should be mandatory, not aspirational. Remote access should be audited. Firmware status should be visible to the people responsible for risk.
The best time to build that model was before deployment. The second-best time is during the next firmware update.
The Charger Is Now Part of the Attack Surface
The ABB Terra AC is not an exotic industrial controller hidden in a fenced substation. It is a Level 2 EV wallbox, the sort of device deployed in commercial garages, fleet depots, apartment buildings, workplaces, and residential installations. That makes this advisory unusually easy to underestimate.The vulnerability sits in the charger’s handling of OCPP, the Open Charge Point Protocol used to connect charging stations to a Charging Station Management System. In plain English, OCPP is the conversation between the charger and the backend that tells it how to authenticate users, report status, receive configuration, and participate in a managed charging network.
That management channel is precisely what gives modern EV infrastructure its value. It also gives attackers a route into devices that used to be thought of as electrical equipment rather than networked computers with safety, billing, and availability implications.
ABB’s warning is direct: a specially crafted OCPP message could pollute heap memory, potentially allowing remote control of the product and writes to flash memory that alter firmware behavior. That is not merely a crash bug. It is the kind of memory-corruption flaw that forces operators to ask whether a device at the edge of their infrastructure can still be trusted after compromise.
Medium Severity Does Not Mean Medium Consequence
The CVSS 3.1 score is 6.8, with a network attack vector, high attack complexity, low privileges required, no user interaction, and high integrity and availability impact. The advisory says confidentiality impact is none, which is one reason the score lands in medium territory. But for EV charging infrastructure, confidentiality is not the whole game.A charger that lies about its state, stops charging vehicles, writes altered behavior to flash, or runs unpredictably can create operational headaches that look very different from classic data theft. In a fleet environment, unavailable chargers can mean vehicles are not ready. In a commercial site, unreliable chargers become support tickets, refunds, angry drivers, and a reputational problem. In a managed energy setting, devices that no longer obey expected behavior can undermine load balancing and demand-response plans.
This is the trap in reading industrial advisories like consumer app release notes. A medium score on a spreadsheet may still describe a vulnerability that matters deeply to the people who own the process, the parking facility, the service contract, or the fleet schedule.
ABB also says it had not received reports of exploitation when the advisory was issued, and that the vulnerability had not been publicly disclosed at that time. That lowers the immediate temperature. It does not eliminate the obligation to patch, especially now that the affected versions, fixed versions, and exploit conditions are public.
The Backend Is the Real Boundary
ABB’s mitigation language is unusually revealing. The advisory says an attacker would generally need to hijack the CSMS backend or exploit unsafe communication between the charger and the backend, particularly HTTP rather than HTTPS/TLS. That framing shifts attention away from the device alone and toward the architecture around it.In many organizations, the charger is treated as a peripheral. The backend is treated as a vendor portal. The network path between them is treated as plumbing. CVE-2025-5517 is a reminder that all three are part of the same trust boundary.
If the CSMS can send commands to the charger, then compromise of the CSMS or its communications path can become compromise of the charger. If the charger accepts malformed management messages badly enough to corrupt heap memory, then the backend channel becomes a delivery mechanism for code execution, denial of service, or firmware-level mischief.
The advisory’s emphasis on TLS is not boilerplate. OCPP has historically allowed deployments over plain HTTP, and vendors have had to support real-world installations where convenience outran security architecture. That may have been tolerable when chargers were isolated gadgets. It is harder to defend when chargers are managed, metered, integrated into business workflows, and deployed in numbers.
Firmware Versions Tell the Operational Story
ABB lists several affected Terra AC variants, and the version matrix is the part administrators should read slowly. Terra AC wallbox UL40/80A versions through 1.8.32 are affected, with 1.8.33 listed as a fixed release. Terra AC wallbox UL32A versions through 1.8.2 are affected, with 1.8.34 as the fix. Terra AC MID, Juno CE, PTB, and JP variants have their own fixed-version targets.That variation is not unusual in embedded products, but it is precisely why asset inventory matters. “We have ABB Terra AC chargers” is not enough information. Operators need the exact model line, regional variant, and firmware version, because the safe endpoint differs across the family.
The advisory also contains a small but important wrinkle: some versions identified in the CISA republication as affected overlap with version numbers also named in the remediation text for certain variants. That is the kind of detail that can happen when vendor CSAF data, product variants, and republication pipelines meet the messy reality of firmware branches. For operators, the answer is not to guess from a headline but to verify against ABB’s product-specific update path and management tooling.
The practical priority is simple: identify Terra AC units, determine the variant, confirm firmware, and move to the fixed release for that variant. If a charger is remotely managed by a third-party CSMS provider, the site owner still needs confirmation that the device firmware and backend transport are secure. Outsourcing the portal does not outsource the risk.
OCPP Security Is No Longer Optional Plumbing
The Open Charge Point Protocol has become one of the quiet enablers of EV infrastructure. It lets operators mix chargers and management systems, integrate payment and authentication, monitor availability, and push configuration changes across fleets of equipment. That openness is a strength.But open protocols do not make insecure deployments safe. They make assumptions visible.
The ABB advisory describes exploitation through a specially crafted OCPP message sent either by a compromised backend or over an unsafe communications path. That is a familiar pattern in industrial and IoT security: the device trusts its management plane, the management plane is exposed or insufficiently hardened, and a protocol feature becomes the attack surface.
The cure is not to abandon OCPP. It is to treat it like a privileged administrative channel. That means TLS by default, certificate validation, backend hardening, monitoring for abnormal command patterns, and segmentation that prevents charger networks from becoming a flat extension of the corporate LAN.
For WindowsForum readers, the analogy is obvious. You would not expose WinRM, RDP, or a domain controller management path casually and then blame Windows when administrative traffic becomes the attack vector. EV chargers deserve the same mental model. They are managed endpoints, and their management channel is privileged.
The “Unsafe Mode” Warning Is the Loudest Sentence
ABB’s recommendation not to use unsafe HTTP mode is phrased bluntly, almost awkwardly, but the message is correct. If a charger speaks to its backend without transport security, an attacker with the right network position can do far more than observe. They can tamper.That is especially relevant in parking structures, campuses, retail sites, and mixed-use developments where network ownership can be fragmented. The facilities team may own the charger. A contractor may have installed it. A managed-service provider may run the backend. The network team may not know precisely what VLAN it is on. The building owner may assume the vendor has handled security.
This is how edge infrastructure becomes vulnerable: not because nobody cares, but because everybody thinks somebody else owns the boundary.
The advisory’s mitigation section reads like standard ICS guidance because the lessons are standard. Minimize network exposure. Put control systems behind firewalls. Isolate operational networks from business networks. Use secure remote access. Perform impact analysis before applying defensive changes. None of that is glamorous, but glamorous security advice is rarely what keeps infrastructure running.
EV Charging Has Crossed Into Industrial Cybersecurity
The CISA classification places this advisory across Commercial Facilities, Critical Manufacturing, Energy, and Transportation Systems. That is the right spread. EV charging is not just a consumer amenity anymore; it sits at the intersection of property operations, energy management, mobility, and industrial maintenance.A workplace charger can be a perk. A depot charger can be mission-critical. A public charger can be part of transportation availability. The same vulnerability can therefore carry very different consequences depending on where the device is installed.
This is why the old consumer IoT framing falls short. A smart bulb going offline is annoying. A charger fleet misbehaving before a morning dispatch window is an operational incident. A managed charging system that can be manipulated may affect not only drivers but also billing, maintenance, utilization data, and electrical load planning.
The industry has been racing to deploy chargers, and reasonably so. Adoption pressure is real. But every charger added to a network is also a small Linux-or-RTOS-flavored computer with firmware, protocol parsers, certificates, logs, update mechanisms, and a vendor support lifecycle. The charging revolution is also an endpoint-management problem.
The Disclosure Trail Shows a Maturing Ecosystem
The vulnerability was reported by Itai Shmueli of Saiflow, according to the advisory, through responsible disclosure. That detail matters because EV charging security research has moved from conference curiosity to regular operational hygiene. Researchers are looking at chargers, backends, roaming protocols, mobile apps, and payment flows because the infrastructure is now worth attacking and worth defending.The advisory also says ABB had no known exploitation at the time of issue. That should be read as a point in favor of patching before urgency becomes panic. The best vulnerability response is boring: disclosure happens, fixed firmware appears, operators update, and the story ends without a breach.
Unfortunately, embedded-device patching is often the opposite of boring. Devices may be installed in places with weak connectivity. Owners may not have portal access. Firmware updates may require installer involvement. Some sites may be nervous about touching equipment that is currently working. A small number of failed updates can sour operators on the entire process.
That is why vendors need to make security updates predictable, reversible where possible, and clearly tied to model-specific release notes. It is also why owners need to treat charger maintenance as part of normal infrastructure operations, not as an exception triggered only when something breaks.
Windows Shops Should Recognize the Pattern
For IT pros, the lesson here is not that ABB is uniquely careless or that EV chargers are uniquely dangerous. The lesson is that the same patterns that defined enterprise endpoint security are now showing up in places that facilities departments historically managed outside the IT stack.There is a networked endpoint. It runs firmware. It accepts remote management commands. It parses structured messages. It has a vendor update channel. It may sit on a segmented network, or it may not. It may use TLS properly, or it may have been deployed in a compatibility mode nobody revisited.
That sounds less like electrical infrastructure and more like a fleet of specialized appliances. Windows administrators have spent two decades learning that specialized appliances still need inventories, patch windows, credentials, certificates, logging, and owners. EV charging networks are now entering that same discipline.
This is also where Windows environments become relevant indirectly. Many charger-management workflows touch Windows desktops, browser portals, exported reports, helpdesk queues, identity providers, or corporate networks. A charger vulnerability may not target Windows, but the operational response will often run through Windows-managed organizations.
The Patch Is Necessary, but Architecture Is the Fix
Updating to the fixed firmware versions is the immediate action. It closes the known parsing flaw ABB identified. But a patched parser does not solve the architectural problem of insecure management paths.Organizations should assume there will be more charger vulnerabilities, not fewer. That is not cynicism; it is the normal path of a maturing technology. More deployments attract more researchers. More integrations create more parsing surfaces. More backend features create more privileged commands. More operational reliance raises the value of disruption.
The durable fix is defense in depth. Chargers should not be directly reachable from the open internet. Charger networks should be segmented. Backend credentials should be protected like administrative credentials. TLS should be mandatory, not aspirational. Remote access should be audited. Firmware status should be visible to the people responsible for risk.
The best time to build that model was before deployment. The second-best time is during the next firmware update.
The Version Numbers That Matter in the Garage
For site owners and administrators, this advisory comes down to a short operational checklist, but the checklist only works if it is tied to the actual ABB variants in the field. The broader lesson is that charger security is no longer a vendor-only concern; it is an asset-management concern.- Terra AC wallbox UL40/80A installations should be checked for affected firmware through 1.8.32 and updated to the fixed 1.8.33 release where applicable.
- Terra AC wallbox UL32A installations should be checked for affected firmware through 1.8.2 and updated to the fixed 1.8.34 release where applicable.
- Terra AC MID, Juno CE, PTB, and JP variants should be verified against ABB’s variant-specific fixed releases rather than treated as a single product line.
- Chargers should use HTTPS/TLS for OCPP communications, and unsafe HTTP mode should be treated as an unacceptable legacy configuration.
- Operators should confirm that the CSMS backend, its credentials, and its network path are secured because the backend is part of the charger’s trust boundary.
- Sites should document who owns charger patching before the next advisory arrives, not during an outage.
References
- Primary source: CISA
Published: 2026-05-26T12:00:00+00:00
ABB Terra AC | CISA
www.cisa.gov
- Related coverage: saiflow.com
ABB Terra AC Buffer Overflow Vulnerability (CVE-2025-5517)
The SaiFlow research team has uncovered a buffer overflow vulnerability in ABB Terra AC chargers, that compromises system integrity. We have demonstrated how we can trigger Denial-of-Service (DoS), making the charger inoperative and unresponsive. The vulnerability could potentially be exploited...
www.saiflow.com
- Related coverage: new.abb.com
