TL;DR (CVE-2026-9037)
Firmware updates with no cryptographic validation (over insecure channels) = guaranteed code execution. We discovered that XCharge C6 chargers have an undocumented firmware update process that can be exploited by attackers to execute arbitrary code on XCharge chargers using a simple archive file with an only MD5 validation, disguising as a firmware update.
Risk implications:
What we found:
- Dangerous feature: DCB firmware update undocumented intentionally execution of script.sh from firmware file as root
- Improper file validation: MD5 checksum only (attacker provides matching hash)
- Multiple entry points: MITM attacks, compromised FTP/HTTP servers, CSMS compromise
Bottom line: This isn't a missing protocol feature, it's a security maturity failure. HTTP/FTP transport + MD5 checksum + script execution flow= RCE by design 💣
Executive Summary
The Firmware OTA Update Attack Surface
Firmware updates are the most powerful attack vector against embedded devices. A successful firmware attack provides:
- Persistent access - Survives reboots and factory resets
- Complete control - Root-level code execution
- Stealth - Appears as legitimate vendor update
- Scale - Single payload deploys to entire fleet
EV chargers receive firmware updates remotely. This is convenient for operators but creates a critical requirement: the entire update chain must be secure-from transport to validation to installation.
The Security Gap
XCharge's firmware update implementation lacks security measures in a few key points:
What's missing in the XCharge DCB update process:
The DCB firmware contains an undocumented feature: if the archive contains a file matching "script", the DCB extracts and executes script.sh as root. Combined with the lack of transport encryption and firmware signing, this transforms firmware delivery into a direct code execution vector.
Multiple Attack Vectors
The insecure update chain creates multiple entry points for attackers:
The XCharge Case
Our research revealed two distinct attack vectors:
- Undocumented script execution - The DCB component in XCharge C6 runs an undocumented feature that when a firmware archive file is downloaded, it looks in the archive for script.sh and executes it as root. This transforms firmware delivery into direct code execution, even without replacing the actual firmware binaries.
- Firmware tampering - Firmware is downloaded over HTTP/FTP with no TLS or cryptographic validation. Threat actors can replace the legitimate firmware file with a malicious one (via MITM or server compromise), and the charger will execute the code without verification of the source.
The DCB runs Linux and controls all safety-critical functions: power delivery, EV communication protocols, and cooling system. Both attack vectors lead to the same outcome: arbitrary code execution on the embedded controller, the DCB.
The Vulnerability: Delivery & Script Execution
The vulnerability's entry points generally fall into three attack vectors:
A. Compromised CSMS
Threat actors who gain access to the CPO's CSMS through a phishing campaign, supply chain attack, or other means can send OCPP FirmwareUpdate messages directing EV chargers to a malicious firmware location.
B. MITM over HTTP/FTP
- EV chargers communicating over unencrypted OCPP connections remain in the wild, leaving firmware update messages including the download URL, exposed to interception and tampering. A man-in-the-middle attacker can redirect the charger to a malicious firmware file.
- Even where OCPP communication is secured with TLS, the firmware download itself is frequently handled over HTTP or FTP, creating a secondary interception point that bypasses TLS of OCPP entirely.
C. Poisoned FTP Server
Threat actors can compromise the file server (FTP or HTTP) hosting legitimate firmware files and silently replace them with malicious binaries.
SaiFlow research team identified poor security hygiene practices across FTP servers managed by CPOs and vendors, including password reuse and excessive permissions to crendetials delegated to EV chargers.
🌻 These findings fall outside the scope of this CVE and will be detailed later in this blog.
Vulnerability Details
1. MD5 Validates Integrity, Not Authenticity
The only validation is an MD5 checksum-which the attacker provides alongside their malicious firmware. MD5 confirms "file wasn't corrupted," not "file came from the vendor." When the attacker controls both the firmware and the checksum, validation always passes.
2. Insecure Transport (OCPP / HTTP / FTP)
Firmware is downloaded over unencrypted HTTP or FTP. An attacker positioned on the network path can intercept downloads and replace them with undetected malicious versions.
3. Script Execution (Backdoor)
The Problem: The DCB firmware contains a backdoor allowing the execute of shell scripts from firmware update files.
This feature was likely intended for vendor maintenance operations and remote support. But without signature validation and with insecure transport, any attacker who can deliver a firmware update can achieve a code execution with the highest privileges.
Vulnerable Code Flow:
get_check_upgarde_file_type()@ 0x516ccthread_File_Oper()@ 0x524f8
// Step 1: DCB lists archive contents
sprintf(cmd, "tar tf %s", firmware_path);
popen(cmd, "r");
// Step 2: Search for "script" in listing
while (fgets(line, sizeof(line), fp)) {
if (strstr(line, "script") != NULL) {
script_found = true;
}
}
// Step 3: If found, extract and validate MD5
if (script_found) {
system("tar xvf firmware.bz2");
system("md5sum -c script.md5"); // Attacker provides valid MD5
set_script_flag(true);
}
// Step 4: Execute the script as root
The FTP Access Control Problem
A significant issue we've observed across the EV charging industry is that FTP servers managed by CPOs and vendors often lack proper access control. Many CPOs and CSMS vendors use a single set of credentials shared across all chargers in a fleet. Moreover, the same credentials are used by the EV chargers to upload diagnostic logs, providing excessive read and write permission to firmware directories (and also tampring log data of other EV chargers).
This creates a dangerous scenario:
- Credential reuse: If an attacker compromises a single charger (via CVE, SSH, Web Admin, or other means), they can extract the FTP credentials
- Excessive permissions: These credentials often grant write access to directories containing firmware files, along with the diagnostic logs upload directory
- No segregation: Diagnostic logs and firmware files are hosted on the same server with the same access controls to all managed EV chargers. Also when a dedicated file server is used for firmware files, all directories and files can be accessed and sometime altered because of missing access controls.
The attack chain becomes:
- Compromise one charger (physical or remote)
- Extract FTP credentials from configuration files or charger logs
- Connect to FTP server using stolen credentials
- Upload malicious firmware to the firmware directory
- Wait for other chargers to update, or trigger updates via compromised CSMS
- Entire fleet compromised from a single initial breach
This transforms a single-charger compromise into a fleet-wide supply chain attack. A single successful threat actor campaign can:
- Deploy backdoors to every managed managed with this vulnerability
- Establish persistence that survives future updates (attacker controls what actually gets installed and executed)
- Exfiltrate CPO and their users (drivers) data
- Coordinate attacks across fleet of EV chargers and potentialy impact the grid
- Denial-of-Charge over the whole fleet and demand ransom
Recommendations For A CPO
- Secure your infrastructure - If you host firmware:
- Use SFTP/HTTPS instead of FTP/HTTP
- Implement strong access controls
- Monitor for unauthorized file changes
- Use the Secure Firmware Update process of the OCPP standard
- Enable security monitoring - SaiFlow can detect:
- Firmware updates from unexpected URLs
- Updates outside maintenance windows
- Bulk update commands targeting entire fleet
- Post-update behavioral changes
- Network segmentation - Limit blast radius:
- Isolate charger management networks
- Restrict CSMS access
- Assume breach and plan accordingly
- Incident response planning - Prepare for fleet-wide compromise:
- Can you rapidly isolate affected chargers?
- Do you have firmware rollback capability?
- How would you detect a supply chain attack?
- Contact your charger vendor
- Request the vendor to use a secure firmware update process
- Enforce a cryptographic signature on the update files
- The EV Charger should reject firmware files that are not signed or have an invalid signature
Conclusion
Key Takeaways
- MD5 is not security when transport is insecure attacker controls both file and checksum
- Insecure transport (HTTP/FTP) enables MITM attacks and makes FTP server compromise devastating
- Intentional script execution is a dangerous "convenience feature" that guarantees RCE and exposed risk when combined with insecure delivery
- Defense-in-depth failure - The MainAndroid boardapp program validates its own updates but the DCB (which controls safety-critical functions) has no validation whatsoever
The Monitoring Gap
Even with improved firmware security, CPOs need visibility into:
- The time windows of when firmware updates occur
- Actual source of a downloaded firmware (DNS query by the EV charger, resolved IP address, network stability, etc.)
- Whether updates succeed, fail or when OCPP notifies on invalid firmware signature
- Post-update EV charger behavior changes
- Malicious or tampered firmware security events
- EV Charger security & diagnostic logs as part of the monitoring system, in addition to OCPP telemetry
CPOs cannot assume backend security protects their fleet. The EV charger itself must also validate the firmware cryptographically.