20 Phoenix Contact CHARX Vulnerabilities Patched: How They Could Have Enabled Deeper EV Charger Control

Key points of this blog 

• Phoenix Contact firmware 1.9.1 addresses 20 vulnerabilities affecting CHARX SEC-3xxx EV charging controllers. Nineteen were reported through Pwn2Own Automotive 2026. 
• The findings highlight three paths to broader compromise: exposed network services, privilege escalation from limited accounts, and insufficiently protected firmware updates. 
• Operators should install and verify firmware 1.9.1, restrict the controllers to closed networks protected by a suitable firewall, and monitor for unexpected activity. 

On July 30, 2026, CERT@VDE published VDE-2026-008, documenting 20 vulnerabilities in Phoenix Contact CHARX SEC-3xxx EV charging controllers. The findings affect the CHARX SEC-3000, SEC-3050, SEC-3100, and SEC-3150 running firmware earlier than version 1.9.1. Phoenix Contact addressed the vulnerabilities in firmware 1.9.1, which was made available by August 12, 2026. 

Most of the findings originated at Pwn2Own Automotive 2026, the automotive zero-day vulnerability discovery competition co-hosted by VicOne and TrendAI Zero Day Initiative (ZDI). The CHARX SEC-3150 was one of the competition’s Level 2 EV charger targets, and 19 of the 20 vulnerabilities addressed by the update were reported through the competition. 

This blog reviews what Phoenix Contact patched, how the vulnerabilities could contribute to broader compromise, and what operators should do next. 

What Phoenix Contact patched in firmware 1.9.1 

The table below lists all 20 vulnerabilities, along with their corresponding ZDI case IDs where available. 

Table 1. The 20 vulnerabilities addressed in firmware 1.9.1 across the Phoenix Contact CHARX SEC-3xxx family 

Although the vulnerabilities affect different components and have different access requirements, they point to three recurring paths through the controller. These involve unauthenticated network services, escalation from limited accounts to root, and insufficiently protected firmware updates. 
 

How these vulnerabilities could lead to broader compromise 

The CHARX controller operates within a wider EV charging environment, connecting charging equipment with local networks, management services, and operator backends.  That position means weaknesses in different layers of the controller can interact in ways that go beyond what any single CVE suggests. The advisory highlights three paths worth understanding together. 

• Network services could provide an initial entry point. Several findings involve services that accept connections without requiring authentication. Weaknesses affecting MQTT, OCPP, JupiCore, and system configuration services could allow unauthorized access to functions or internal resources that should otherwise be restricted. An exposed service of this kind can serve as the starting point for further activity, particularly when combined with other weaknesses. 
• Privilege escalation could increase the impact. Multiple findings involve paths from restricted service accounts to root. This matters because even a limited initial foothold can become a much more significant one if privilege boundaries are not enforced. The number of escalation paths identified here underscores how much depends on keeping service-account permissions tightly scoped. 
• Firmware weaknesses could affect device integrity. Attacker-controlled update paths and inadequate firmware verification could reduce assurance that firmware running on the device actually originates from a trusted source and has not been modified. This is particularly relevant in operational environments where firmware integrity is assumed rather than actively verified. 

These attack paths show how an exposed service, a limited foothold, or a weakness in the firmware update process could provide a path to deeper control of an EV charger, and through it, to the wider charging infrastructure it connects to. 

What operators should do next 

Operators using affected CHARX SEC-3xxx controllers should take the following steps: 

• Update and verify: Install firmware 1.9.1 from the appropriate Phoenix Contact product page, plan for the required system restart, and confirm the installed version afterward. 
• Restrict network access: Following Phoenix Contact’s guidance, operate the controllers exclusively within closed industrial networks protected by a suitable firewall. Limit MQTT, OCPP, Modbus, management, and firmware-update services to authorized systems and users. 
• Monitor for unexpected activity: Review unexplained configuration changes, firmware downloads, controller reboots, and charging interruptions that could indicate attempted exploitation. 

Firmware 1.9.1 addresses the vulnerabilities documented in this advisory, but applying the update is only one part of reducing risk. As EV chargers operate as connected components of a wider charging ecosystem, securing them also requires network segmentation, controlled access, and continued monitoring throughout their operational life. 

Frequently asked questions 

Can these vulnerabilities affect systems beyond the EV charger? 

The controller connects charging equipment with local networks, management services, and operator backends. Although compromise of one controller does not automatically extend to these systems, inadequate segmentation or access controls could increase the potential impact. Addressing this broader exposure requires security measures that extend beyond patching the controller itself. 

What security capabilities can help address this broader EVSE exposure? 

An electric vehicle supply equipment (EVSE) security solution should provide vulnerability management, firmware and software component visibility, intrusion detection and prevention, and continuous monitoring. It should also account for the connections among charging controllers, management systems, backend services, and vehicles.  

How can VicOne help protect EVSE controllers? 

VicOne helps EVSE manufacturers and operators identify and manage cyber risks before and after deployment. xZETA supports firmware vulnerability and software bill of materials (SBOM) management, while xNexus provides cloud-based detection and response. 

To learn more, explore VicOne’s EV Charging System Protection. 

 
A background on coordinated disclosure timelines  
The timeline of public vulnerability disclosures can seem unclear to many. For example, there is often a delay between TrendAI ZDI’s announcement that a team has successfully hacked or “pwned” a device at a Pwn2Own event and the subsequent publication of the techniques used in the attack. This delay is part of the coordinated vulnerability disclosure (CVD) process, which aims to manage zero-day vulnerabilities responsibly.  

In the 1990s, only a small number of hackers actively searched for vulnerabilities, and many vendors were unprepared to handle them. Concerns arose from both sides: “Are hackers submitting vulnerabilities in exchange for benefits?” and “Will these vulnerabilities actually be fixed, or will the effort be wasted?” The compromise became clear: Hackers would first submit vulnerabilities to vendors, who would then release a patch and publicly acknowledge the researchers for their discovery.  

According to TrendAI ZDI’s disclosure policy, a submitted vulnerability is disclosed when a patch becomes available — or after a certain period if the vendor remains unresponsive. This approach either addresses the vulnerability or informs the public about an unresolved issue, reducing the likelihood of exploitation. This explains the time gap between initial discovery and full public disclosure.