The vulnerability discussed hereunder, CVE-2025-5517, affect all the ABB Terra AC charging stations with versions until 1.8.32 including (affected versions may differ by product variant, refer to the advisory for more details). It is recommended to update to the latest firmware version, already published and provided by ABB, as soon as possible and follow the mitigation steps below.
- ABB Terra AC models have multiple variants, please refer to the ABB security advisory - link.
TL;DR
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 to achieve RCE. Exploitation of the vulnerability requires MITM capabilities with unencrypted communication, or a compromised Charging Station Management System (CSMS).
EV adoption accelerates; Its charging infrastructure becomes a vital part of our energy ecosystem - yet it remains dangerously exposed to cyber attacks. At SaiFlow, we believe that securing EV charging and distributed energy networks is not just a technical necessity, but a shared responsibility.
SaiFlow’s research team has uncovered yet another vulnerability, this time in ABB’s widely deployed AC chargers. The flaw allows a remote attacker to crash chargers and become unresponsive with a single OCPP message, potentially triggering large-scale Denial-of-Charge (DoC) scenarios.
This discovery adds to a growing list of vulnerabilities we’ve identified across the ecosystem. At SaiFlow, we’re committed to helping secure the EV and energy landscape through proactive research and industry collaboration. We’re here to help operators, vendors, and regulators build a safer, smarter energy future.
ABB Terra AC Buffer Overflow Vulnerability (CVE-2025-5517)
As classic memory corruption vulnerabilities plague the embedded world, I find publishing this blog post an opportune time to not only discuss the vulnerability we’ve uncovered, but prevention as well.
In the meantime, let's meet our subject:
Yes - an EV charger.
"But why should I care about a Buffer Overflow in an EV charger anymore than I would in my toaster?"
- You might ask.
Well, it should come as no surprise to anyone by now that this device is internet-connected. Not only is it internet-connected, but it, and others like it, can operate as part of a charging network. That opens the door to a plethora of attack scenarios, like energy theft, Denial-of-Service, becoming an attack vector to EVs (yes, some chargers even allow the EV to connect over IPv6), and even compromising the grid itself - but that tangent is probably worthy of its own blog post.
Hardware Teardown
During the research that led to this vulnerability, we reverse engineered the firmware and hardware of the ABB Terra AC EV charger. To begin with the hardware side of things, we disassembled the device and identified the main components:
After identifying the relevant ICs, we could, for example, identify MMIO registers, match them to the physical pins, and trace them to the components they are connected to.
Afterwards, we powered on the logic board assembly:
That allowed us to capture communications between the ICs.
Reversing The Firmware
First Look
Once we got our hands on the firmware, we started reverse engineering it.
It became apparent fairly quickly that some code references don’t really line up, and the beginning of the image doesn’t really look like a vector table. So what’s going on?
There are some patterns that immediately stand out.
First, the byte sequence 00 01 08 03, which matches very closely the version of the firmware itself (v1.8.30), occurs twice at the beginning of the firmware binary. The small mismatch is probably a typo, either here, or in the logs of the firmware itself that also report the version.
At this point, it’s fair to assume we’re dealing with packaged firmware, and not a plain binary.
Immediately after each version field, there is a 4-byte word. Those add up very closely to the size of the binary itself. We can also tell from Binary Ninja’s memory feature map that there’s a “break” that lines up with those sizes:
From that, we gather that the package probably contains two segments, which explains why the patterns repeat twice.
After the size field, there’s another 4-byte word, which we assumed (and later confirmed by analyzing the code) is a CRC32 checksum. The package header also contains a cryptographic signature to validate the authenticity of the firmware. Vendor signed firmware updates are a good practice, and an excellent move on ABB’s part, as it means that a compromised backend, network misconfiguration, or even mere network access for attackers - won’t immediately make the charger vulnerable to RCE.
The Offset
The next thing we had to figure out was the offset of the code, since placing it at the address mapped to the start of the flash (0x08000000 for this controller) did not produce the desired results.
From here, there are at least two ways to go about finding the offset:
1) The beginning of the package data does look like a legitimate vector table, so look for code reference to 0xe000ed08 (VTOR - vector table offset register) to see what is assigned to it.
2) Look for a code reference you also know the target of. For FreeRTOS, a good option is xTaskCreate since it has a fairly distinct signature, and the task name can tip you off as to what’s the role of the task.
Exploring The Code
Once we could properly map the first segment of the package to the memory space, we started exploring the code. Some notable key points of interest:
xTaskCreate,xQueueGenericSend,xQueueGenericCreate,… - key FreeRTOS functions that will help you track the flow of code and data. Those APIs are related to task and message queue management. The function for creating a task, for example, receives a function pointer and a name describing it. The functions for queue management either return or receive a queue handle, which can help track down the message flow between tasks.- libc methods
- JSON parser methods
- Reset vector - Finding the entry point is fairly useful because it allows the reversing tool of your choice to recursively analyze all functions by reference. In our case, Binary Ninja already identified the entry point as a function, but if it hadn’t, the vector table is a good place to find it.
Buffer Overflow
Let's have a look at the vulnerable code itself:
As you can see, a string of unknown size is copied into a fixed-size buffer - a classic case of buffer overflow. (Why use sprintf for this - idk).
Indeed, supplying a very long string crashed the charger:
[
2,
"msg-id-0",
"DataTransfer",
{
"messageId": "sdfgf...f", // Very long input
"vendorId": "vendor-id",
"data": "{ \"type\": \"RemoteControl\", \"cmd\": \"\", \"raw\": \"\" }"
}
]Where is this string coming from?
It's the ID of a message sent from the central charging station management system (CSMS) to the charger (EVSE) over websocket (OCPP over websocket in this case).
So exploiting this does require either a compromised CSMS (Figure 1.A) or a MITM (Figure 1.B) with non-TLS traffic. Sadly, SaiFlow has encountered plenty of chargers that don't encrypt their communications. As for gaining MITM capabilities, it can be as simple as disconnecting an Ethernet cable and literally placing yourself in the middle, or exploiting a weak WiFi password / no password - allowing for easy MITM. Just connect to LAN and ARP-spoof the EV charger to think the attacker device is the gateway to the internet.
To an attacker's delight, RTOS-based firmwares, such as in this case, rarely implement any memory corruption mitigations on the OS side, and are prone to occurrences of such vulnerabilities in general, as they’re almost always coded in C.
The vulnerability we’ve discovered allows an attacker to overwrite subsequent chunks on the heap. Once an attacker can do that, they can utilize one of the many well-documented techniques available to achieve remote code execution. The predictable nature of memory placement in RTOS systems also helps in that regard.
To give safe/unsafe unlink as an example, you manipulate the header of the next chunk, overwriting the next/previous chunk pointer and size, in a way that would lead the unlink process to create a chunk at an arbitrary address. Then, in a subsequent allocation, overwrite the desired data (e.g. a function pointer) with attacker provided data (e.g. pointer to shellcode).
For a detailed description and walkthrough of classic heap exploitation techniques, The following articles are recommended:
- Overview of GLIBC heap exploitation techniques
- Exploring Heap Exploitation Mechanisms: Understanding the House of Force Technique
- Heap exploitation, glibc internals and nifty tricks.
Potential Impact
While we briefly mentioned several attack scenarios earlier, it is worth expanding on their potential impact.
An unsophisticated buffer overflow yielded in our testing an unresponsive firmware - indefinitely, causing a Denial-of-Service. Meaning that a resolution would require personnel to physically arrive at the charging site and perform a manual reset to the charger. If coordinated, such an attack could disable an entire charging network for prolonged periods of time.
Potentially, the buffer overflow could provide attackers an RCE to initiate unauthorized charging sessions (energy theft), or even compromise the grid, given a sufficient number of chargers. Researchers at Princeton have demonstrated several methods for a botnet comprised of high-wattage IoT devices to compromise the grid. One being shifting the grid’s frequency beyond the cut-off threshold. This can be done by synchronously powering on/off the botnet’s devices, which dramatically increases/decreases the load on the grid, resulting in a grid frequency decrease/increase appropriately. The reason that, somewhat counterintuitively, a load decrease can result in an outage is that the grid has a cut-off threshold for too high frequencies for their generators as well.
Suggestions for Vendors
Vendors can adopt several proven techniques to prevent and detect vulnerabilities of this type. A comprehensive security approach should incorporate the following methods:
- Static Analysis Scanners
- Accessors
- Secure String and Buffer APIs
- Fuzzers
- Model Checking
- Monitoring
Each of these techniques addresses different aspects of the development and deployment lifecycle, providing defense-in-depth against potential security flaws.
Static Analysis Scanners
A static analysis scanner can detect a lot of issues - but not all.
Where do you want it integrated?
- IDE - the shorter the feedback cycle is between scanners (or linters for that matter) and developers, the more effective it is.
- CI/CD - there's no reason that violating code would even be able to merge into
dev, unless it was already individually addressed.
Accessors
Wrap buffers with accessors that validate string length.
- It becomes a lot easier to manage and enforce secure practices when operations on a buffer take place in central accessors.
- It's just a better practice overall. Why deal with bound checking over and over again, when you can just address it once?
Secure String and Buffer APIs
The usage of functions like sprintf or strcpy should automatically be flagged! Configure your linter to do so. At the very least, you should use their length limited variants like snprintf, strncpy, and, if available, strlcpy.
As a researcher, I can tell you that finding such functions in my research subject is a “happy” moment.
It gives me an easy starting point, with a relatively high probability for bugs.
Fuzzers
Just like static analysis scanners, fuzzers are a class of automation tools.
They might have a more involved setup, but in return, they help tackle the dynamic side of things - detect bugs at runtime.
Integrate fuzzers into the CI/CD process similarly to how you would a static analysis scanner.
For a real-world example, here’s Microsoft’s documentation on fuzzing their own Terminal app:
Terminal fuzzing.md
Fuzzers are vastly underrated, especially considering your adversaries will certainly keep them in their tool belts.
Model Checking
If you really want to ensure the memory safety of your code, you can utilize a model checking tool.
Essentially proving that given certain assumptions - certain conditions can/cannot happen (such as an out of bound write).
For this, I'm gonna defer to FreeRTOS's blog-posts by Nathan Chong on how they ensured the memory safety of components of their network stack.
Monitoring
Vendors that offer an in-house CSMS solution can have unique insights in terms of monitoring. They’re able to define abnormal behavior more concisely than a CPO might be able to. On top of that, they’re exposed to data from a wide range of Charge Point Operators (CPOs), allowing for more opportunities to correlate events.
Suggestions for Charge Point Operators (CPOs)
Security responsibility extends beyond vendors to the operators who deploy and manage charging infrastructure. CPOs should adopt the following operational security practices:
- Keep Firmware Up-To-Date
- Vulnerability Management
- Secure Communication
- Monitoring
By maintaining vigilant operational security practices, CPOs create an additional defensive layer that complements vendor-level protections.
Keep Firmware Up-To-Date
Stay tuned for new firmware releases, as they might feature patches for security vulnerabilities.
Vulnerability Management
Keep track of your chargers' SBOM and in-turn, their disclosed vulnerabilities.
Secure Communication
Verify that all your chargers communicate over TLS/SSH, e.g. https:// and ftps://, or sftp://, as opposed to http:// and ftp://.
Monitoring
Monitoring your chargers' activities by examining their network communications, diagnostics logs, and configuration for abnormal behavior or indicators of known malicious activity - is crucial for detecting compromised assets and ongoing attacks.
About SaiFlow
But what if you don’t get to have a say about the code of your chargers? Worried about leaving your smart meter alone at night? Uncertainty about adversaries manipulating your BESS keeps you up at night?
SaiFlow is the leading cybersecurity company dedicated to protecting EV charging and distributed energy networks - including charging stations, BESS, solar power plants, and microgrids.
SaiFlow’s platform delivers contextual, energy-aware security by fusing three critical dimensions:
- Energy telemetry (power flows, voltage patterns, anomalies)
- Network activity (OCPP/OCPI, IEC 61850, Modbus, OpenADR, and more)
- Asset and posture data (device visibility, configurations, vulnerabilities)
By correlating these data streams, SaiFlow provides full asset visibility, continuous cyber monitoring, and real-time anomaly detection tailored for modern energy networks.