TL;DR: Firmware 1.9.1 for Phoenix Contact CHARX SEC-3xxx EV charging controllers fixes 20 vulnerabilities, including exposed services, privilege escalation from limited accounts, and weak firmware update handling that could enable broader compromise across connected charging environments, according to VicOne. Patch verification and network restriction matter because device integrity depends on more than remediation alone.
At a glance
What this is: This blog reviews 20 vulnerabilities in Phoenix Contact CHARX SEC-3xxx EV charging controllers and shows how exposed services, privilege escalation, and weak firmware update controls can combine into broader compromise.
Why it matters: It matters because EV charging controllers sit inside operational networks where weak service boundaries, unverified firmware, and poor segmentation can turn a device flaw into a wider environment risk for operators and security teams.
Context
EV charging controllers are connected devices that sit between local networks, management systems, and backend services, so a weakness in one layer can become an entry point into the wider charging environment. The problem is not only patching individual CVEs, but governing who can reach the device, what can be reconfigured remotely, and whether firmware integrity is actually verified.
This advisory is a useful reminder that industrial and embedded environments often fail at the boundaries first: unauthenticated services, weak privilege separation, and update trust assumptions. The starting position here is typical for connected operational technology, where device security is often treated as a patching exercise rather than a lifecycle governance problem.
Key questions
Q: What fails when EV charging controllers expose unauthenticated services?
A: Unauthenticated services turn a managed device into an exposed control surface. They let an attacker reach internal functions without proving identity first, which means configuration, backend integration, or maintenance features can be probed and abused before any privilege boundary is enforced. In connected operational environments, that first foothold often matters more than the specific bug because it opens the path to deeper compromise.
Q: Why do limited accounts become dangerous on embedded controllers?
A: Because restricted local access often sits closer to root than teams expect. If privilege boundaries are weak, a low-level account can escalate into administrative control, which turns a minor foothold into full device compromise. That is especially risky on controllers that also handle configuration, charging logic, or update workflows, because root access can affect availability and trust at the same time.
Q: What are the signs that firmware update trust is failing?
A: Look for unsigned or unexpectedly accepted images, repeated update retries, unexplained cleanup behaviour, and firmware changes that cannot be tied to an authorised maintenance process. When those signals appear, the issue is not just patch hygiene. It indicates that the device may be accepting or retaining code without reliable provenance checks, which undermines confidence in the running image.
Q: How should operators reduce the blast radius of EV charger compromise?
A: They should combine patching with hard network segmentation, strict service reachability, and continuous monitoring of controller behaviour. The goal is to prevent a single device flaw from becoming a broader trust problem across management systems or backend services. That requires treating the charger as part of a connected environment with explicit access boundaries, not as an isolated appliance.
Technical breakdown
Unauthenticated services create the first foothold
Several patched issues affected MQTT, OCPP, JupiCore, Modbus TCP, and system configuration services that could be reached without proper authentication. In practice, exposed services do not just leak functions, they create a path for an attacker to reach internal device capabilities that were meant to be reserved for trusted operators or backend systems. Once a service accepts unauthorised requests, the security boundary shifts from access control to exploitation potential. For connected chargers, that boundary matters because device management, charging logic, and firmware operations are often exposed through the same network plane. See the Broken Access Control Prevention Guide.
Practical implication: Restrict exposed controller services to approved management paths and assume every unauthenticated endpoint is a potential entry point.
Limited accounts should not be able to cross into root
The update also fixed multiple local privilege escalation paths from restricted accounts to root, which shows that access scope and execution context were not sufficiently separated. Privilege escalation is especially damaging in embedded systems because an initial low-level foothold can become full device control, including the ability to alter configuration, stop services, or interfere with update logic. These weaknesses are not only about authentication failures. They are about the control plane allowing a limited identity to cross into a higher trust domain that should have remained isolated. See the NHI Lifecycle Management Guide.
Practical implication: Treat service-account permissions as a hard security boundary and test whether restricted identities can reach administrative functions.
Firmware update trust has to be verified, not assumed
Several findings affected firmware-signature verification, firmware cleanup, and update-related file handling. That pattern matters because attackers do not need to fully own a device if they can tamper with what the device accepts as trusted firmware or alter update workflows. Integrity controls should confirm both origin and state, meaning the device must verify that a firmware image is genuine and that the update path cannot be abused to replace or persist malicious code. In operational environments, update trust is often assumed after the patch process begins; these findings show why that assumption is too weak.
Practical implication: Verify firmware provenance and update integrity on every affected controller before and after deployment.
Threat narrative
Attacker objective: The attacker aims to gain deeper control of the EV charging controller and use that position to disrupt operations or manipulate the wider charging environment.
- Entry occurs through unauthenticated network services such as MQTT, OCPP, Modbus, or configuration endpoints that accept requests without proper verification.
- Escalation follows when a limited account or low-privilege foothold can move to root through local privilege escalation flaws or insecure recovery logic.
- Impact comes from device takeover, reconfiguration, reboot disruption, or tampering with firmware so the charger and its connected environment can no longer be trusted.
Breaches seen in the wild
- HPE Aruba Instant On hard-coded credentials: Hard-coded admin credentials in HPE Aruba Instant On access point firmware let anyone bypass login (CVE-2025-37103); no exploitation reported.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
These findings are best understood as control-plane failures, not isolated bugs. The article shows three recurring paths: unauthenticated service access, local privilege escalation, and weak firmware integrity. That combination matters because each path weakens a different trust boundary in the same device stack. For operators, the practical lesson is that charger security depends on how identity, access, and update trust are governed together, not on patching one layer in isolation.
Identity scope is the hidden fault line in embedded and industrial controllers. A limited account should not be able to become root, yet multiple paths in this advisory show exactly that failure mode. This is where least privilege becomes an operational control rather than a policy phrase, especially when service accounts and maintenance identities are involved. The governance gap is the assumption that internal accounts are harmless because they are local; in practice, local accounts often become the most useful pivot point for compromise.
Firmware trust deserves the same scrutiny as authentication trust. If a device cannot reliably verify what it is loading, the update process itself becomes part of the attack surface. That is especially relevant for connected operational assets where remote maintenance is normal and patch windows are short. The security model breaks when organisations assume an installed image is trustworthy simply because it came through an update channel.
Visibility into NHI and device trust gaps is still the hardest control to operationalise. Connected devices, backend services, and operator tooling often share the same environment without clear inventory or ownership boundaries. When visibility is weak, exposed services and update paths remain reachable long after teams believe they are controlled. The practitioner implication is straightforward: govern the device as part of a connected trust chain, not as a standalone appliance.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Firmware trust is now an operational governance issue, not a maintenance detail. When update paths are exposed to arbitrary upload, missing signature verification, or insecure recovery logic, the organisation has no reliable assurance that the device state matches the approved state. For EVSE programmes, that means patching must be paired with provenance checks and post-update validation.
Service account visibility is the control that often determines whether embedded compromise stays local. Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. In a controller environment, that visibility gap makes it harder to detect which identities can reach management functions or escalation paths, so the issue is governance as much as vulnerability management.
For practitioners
- Install firmware 1.9.1 and verify the running version Apply the corrected firmware to affected CHARX SEC-3xxx controllers, then confirm the installed version after restart so the remediation is not assumed rather than verified.
- Constrain controllers to closed industrial networks Place MQTT, OCPP, Modbus, management, and firmware-update services behind a suitable firewall and limit reachability to authorised systems and users only.
- Review configuration and reboot anomalies Watch for unexpected configuration changes, firmware downloads, repeated reboots, and charging interruptions, because these are the operational signals most consistent with attempted exploitation.
- Audit service-account permissions on the charging stack Check whether restricted service identities can reach administrative interfaces, startup scripts, or recovery paths that should remain outside their scope.
- Validate firmware update integrity end to end Confirm that firmware images are signed, accepted only from trusted sources, and not replaceable through alternate upload or cleanup paths.
Key takeaways
- The advisory shows that EV charger compromise can start with exposed services, move through privilege escalation, and end in device or environment-level disruption.
- The update fixed 20 vulnerabilities, 19 of them reported through Pwn2Own Automotive 2026, which shows how many distinct paths to compromise existed before remediation.
- Operators need to treat firmware verification, service reachability, and account scope as linked controls, because patching alone does not close every trust gap.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Ultimate Guide to NHIs: Key Challenges and Risks · Zero-Day and Exploited Vulnerabilities Guide · HPE Aruba Instant On hard-coded credentials
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes service exposure and privilege escalation paths that enable attacker movement through the device. |
| Recommendation — Map exposed controller services and escalation paths to TA0006 and TA0008, then prioritise the reachable attack surface. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Restricted accounts reaching root shows a failure of permissions and authorisation boundaries. |
| Recommendation — Review controller entitlements against PR.AA-05 and remove any path from limited access to administrative control. | ||
| CIS Controls v8 | CIS-5 — Account Management | The advisory highlights service-account scope and local account exposure as governance problems. |
| Recommendation — Apply CIS-5 to inventory controller accounts, scope privileges tightly, and retire unnecessary access paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The update and service-access issues point to weak credential and authenticator lifecycle control. |
| Recommendation — Use IA-5 to govern controller authenticators, including rotation, verification, and revocation where needed. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Service identities and device accounts with excessive privilege are central to the escalation paths described. |
| Recommendation — Reduce NHI privilege scope so service accounts cannot cross into administrative device control. | ||
Key terms
- Firmware Integrity: Firmware integrity is the assurance that device code has not been changed, corrupted, or replaced by an unauthorized party. It is commonly enforced through signature checks, cryptographic hashes, and secure boot validation. Without integrity checks, devices may accept untrusted firmware and execute attacker-controlled code.
- Privilege Escalation: An attack technique where a compromised identity, often an NHI with initially limited permissions, exploits vulnerabilities or misconfigurations to gain elevated access rights, typically leading to broader compromise.
- Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
- Closed Industrial Network: A closed industrial network is a segmented environment that limits device communication to authorised systems and controlled pathways. It reduces exposure from internet-facing or broadly reachable services, but it only works when reachability, firewall policy, and trust boundaries are actively enforced and maintained.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is suited to practitioners who need to connect identity governance to adjacent security controls and operational risk.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org