The Hidden CCS2 Attack Surface on EV Chargers https://t.co/0rIE0hbHnS

The Hidden CCS2 Attack Surface on EV Chargers

Source: https://www.saiflow.com/blog/the-hidden-ccs2-attack-surface-on-ev-chargers

TL;DR (CVE-2026-9039)

An EV charger’s charging port is a network port.We found SSH and Telnet services exposed on XCharge C6 chargers with defaultroot:rootcredentials. A threat actor with a malicious EV cangain immediate full control access on the charger and perform energy theft or potentially cause physical damage.

ScenarioBusiness ImpactFleet compromiseBackdoors installed across the charging networkCPO network breachLateral movement via charger backbone connectivitySafety incidentPower and thermal parameter manipulationSupply chain attackCompromised charger infects connecteding EVs What we found:

• SSH/Telnet bound to all interfaces (0\.0\.0\.0)
• Default credentials:root:root
• No authentication hardening (rate limiting, lockout)
• Pattern likely exists across multiple vendors

Bottom line:Plug in, SSH in, you’re root.

‍

Executive Summary

The Overlooked Attack Surface

The EV charging industry has well-established security standards. OCPP (Open Charge Point Protocol) provides clear guidelines for securing the communication channel between EV Chargers and the Charging Station Management System (CSMS): use VPNs or Private APNs, implement OCPP Security Profile 2 or higher, enforce TLS mutual authentication etc. When properly configured, these measures make it significantly harder for threat actors to compromise the management channel.

But what about the other side of the charger?

While the industry has focused on securing the backend communication, the attack surface exposed through the CCS2 charging plug remains largely untested.

Every time an EV connects to a charger, it establishes an IP network over Power Line Communication (PLC). This network was designed for V2G protocols.But we also discovered other EV charger operating system services listening on these network interfaces.

‍

Why This Matters

From a traditional IT security perspective, think of this attack vector as analogous to an attacker having a port in the corporate LAN.The scenario is identical, except the port isn’t an RJ45 jack in the office, it’s a CCS2 connector in a parking lot.

This has profound implications: compromised EV chargers can serve as a foothold into CPO (Charge Point Operator) private networks. Since chargers often connect to backend systems via VPN or Private APN infrastructure, an attacker with access to a charger could potentially pivot to back-office systems, billing platforms, or other critical infrastructure.

‍

The Finding

We discovered that the XCharge C6 charger exposes administrative services (SSH and Telnet) on all network interfaces, including the PLC interfaces accessible from connected EVs. Combined with the trivial passwordrootfor the userroot, provides immediate privileged user access to anyone who can plug into the charging port.

‍

What Can a Threat Actor Do?

Once an attacker gains full control on the charger’s DCB, the described below primary attack scenarios emerge:

The full breakdown is shown in ourprevious blogcovering SLAC protocol exploit to gain RCE.

‍

The Attack Surface: CCS2 as a Network Interface

Most people think of the CCS2 charging plug as just a power connector. It’s not.It’s also a network interface.

When an EV plugs in, the charger and vehicle establish an IPv6 network link over the charging cable using HomePlug Green PHY (powerline communication). This network is intended for V2G charging protocols - but any service listening on all interfaces becomes accessible.

The bottom line:Plug in a CCS2 device → Get an IPv6 address → Access any exposed service.

‍

The Vulnerability: Exposed Administrative Services

Our reconnaissance revealed the following listening services on the DCB of XCharge C6:

‍

The DCB has multiple network interfaces:(addresses are masked with `?`)

InterfacePurposeAccessible from EVcan0CAN bus (internal)Noeth0Management networkNoloLoopbackNoqca0PLC modem - CCS2 Gun 1YESqca1PLC modem - CCS2 Gun 2YES When a service binds to0\.0\.0\.0or\[::\], it listens on every network interface - including:

• CCS2 (PLC) interfaces(qca0, qca1) accessible from the connected EV
• Internal management interface (eth0)

‍

What Services Are Exposed?

ServicePortPurposeShould Be Exposed to EV?SSH (Dropbear)22Remote administrationNO - MisconfigurationTelnet (BusyBox)23Remote administrationNO - MisconfigurationV2G (SECC)15118ISO 15118 / DIN 70121 charging protocolYes - Required for charging ‍

The Vulnerability: Default Credentials

The root account uses a trivially weak password:root

This is one of themost common default passwordsin embedded systems, and it was never changed before deployment.

No Authentication Hardening:

• No rate limiting on login attempts
• No account lockout after failed attempts
• No multi-factor authentication
• Default credentials shipped to production

‍

Attack Walkthrough

Hardware Requirements

The attacker needs CCS2-compatible hardware:

• CP (Control Pilot) control - Ability to pull CP voltage to 9V/6V [~5-10$]
• PLC modem - HomePlug Green PHY capable device (e.g., QCA7000/QCA7005) [$70]
• Mini computer - Raspberry Pi [~50$]
• Physical access - 2 wires connecting to the CCS2 charging plug

Total hardware cost: 130$

‍

Step-by-Step Exploitation

‍

Post-Exploitation Capabilities

With root access, an attacker can:

• Steal SECC certificate- Impersonate the charger used for Plug & Charge authentication
• Manipulate charging- Bypass power limits, alter metering
• Install backdoor- Persistent access via cron/init scripts
• Pivot to CPO network- Attack CPO network via VPN/APN connection*(Depending on the charger system architecture)*
• Brick device- Ransomware or execution of destructive actions
• Disable safety systems- Cooling, overcurrent protection

‍

Broader Industry Implications

This Is Not Unique to XCharge

While our research focused on the XCharge C6,the vulnerability pattern we discovered is common across the EV Chargers industry:

Common anti-patterns:

• Servicesbound to all network interfacesby default
• Weak/default credentialsshipped to customers
• No separationbetween management and operational interfaces

‍

Recommendation for CPOs

1. Immediate:Monitor for abnormal V2G and SLAC communicationthrough the diagnostic logs of the EV charger. Also,Monitor for power consumption and cross-correlate with other power metering devices(if available) to detect energy theft or manipulation. Watch for unexpected network connections, authentication failures, or operational irregularities.
2. Immediate: Make sure yourXCharge is updated and runs the latest versionafter May 22nd
3. Short-term: Request firmware update from vendor that binds SSH to management interface only, uses unique credentials, and provides a dedicated non-root user.
4. Short-term: Implement network segmentation between chargers and backend services to limit lateral movement.
5. Long-term: Require vendors to provide security patches and recurring security assurance through penetration testing or independent security assessments of their products.

Example: The XCharge C6 uses OpenV2G version 0.9.4 (from 2020), which contains known buffer overflow vulnerabilities in X509 certificate parsing:CVE-2022-27242andCVE-2025-24956(CVSS 9.8 Critical). Regular security assessments would have identified these outdated dependencies.

‍

For EV Charger Vendors

• Generate unique password per device during manufacturing
• Don’t use passwords derived from known information such as device serial number
• Bind administrative services to management interfaces only - not 0.0.0.0

‍

Why Exposed Services on CCS2 Are a Ticking Time Bomb

The XCharge case demonstrates how close we came to a zero-credential compromise - and why exposing administrative services on CCS2 is inherently dangerous.

CVEServiceTypeSeverityStatus on XChargeCVE-2016-7406Dropbear SSHPre-auth RCE (format string)Critical (9.8)Patched (v2016.74 exact)CVE-2026-24061GNU TelnetdAuth bypass (-f root)Critical (9.8)Different software Dropbear SSH: The charger runs Dropbear v2016.74 - the exact version that patched CVE-2016-7406. One version earlier, and attackers would have had pre-authentication root shells without needing any credentials.

GNU Telnetd: CVE-2026-24061 (January 2026) allows authentication bypass on GNU inetutils telnetd via a trivial environment variable injection. While XCharge uses BusyBox telnet, this CVE demonstrates that telnet services are actively targeted and fundamentally unsafe to expose.

‍The lesson: Even if today’s credentials are “only” weak defaults, tomorrow’s CVE could eliminate the need for credentials entirely. Services exposed on CCS2 inherit all future vulnerabilities in those service implementations.

‍

Conclusion

The charging port is a network port - treat it like one.

This research demonstrates that EV chargers can be compromised through the CCS2 charging interface when administrative services are misconfigured. The combination of:

1. Services bound to all interfaces (0\.0\.0\.0/\[::\])
2. Default weak credentials (root:root)
3. No authentication hardening (such as certificate based authentication)

The above creates a trivially exploitable attack path that requires only physical access to a public EV charging port.

Key takeaways

FindingImplicationSSH/Telnet on PLC interfacesCCS2 exposes more than V2G protocolsDefault root:root passwordBasic credential hygiene failuresNo interface bindingDefense-in-depth completely absentIndustry-wide patternThis is not unique to one vendor As EV infrastructure scales globally,these devices must be treated as critical infrastructure. The attack surface exposed via the charging cable is as dangerous as network-exposed services. It requires only physical access to a public charging port.

Plug in. SSH in. You’re root.

‍