CVE-2026-44104 affects Phoenix Contact CHARX SEC3xxx electric vehicle charging controllers used to manage charging infrastructure. The issue is especially important for organizations operating public charging stations, workplace charging networks, fleet facilities, commercial properties, and industrial sites across the United States and Canada.
If your organization relies on these controllers, a compromise could interrupt charging operations, expose connected systems, create safety and business continuity concerns, and damage customer trust. The risk is not limited to the charging equipment itself because charging infrastructure commonly connects to management platforms, payment services, building systems, and operational networks.
This article explains why the vulnerability matters to business leaders, how to determine whether your organization is exposed, what real-world consequences could look like, and how to coordinate an effective response. A technical appendix provides verification and remediation guidance for security engineers, penetration testers, and information technology professionals.
CVE-2026-44104 was publicly disclosed on July 30, 2026, following coordinated reporting involving the Zero Day Initiative and CERT VDE. The vulnerability affects the firmware update process in the basemodule of Phoenix Contact CHARX SEC-3000, SEC-3050, SEC-3100, and SEC-3150 charging controllers when running firmware earlier than version 1.9.1. CERT VDE identifies the weakness as improper verification of a cryptographic signature, or CWE-347.certvde
The official advisory rates the issue as critical with a CVSS 3.1 score of 9.8. The National Vulnerability Database also lists a critical CVSS 4.0 score of 9.3. The scoring difference reflects different scoring frameworks, but both assessments indicate a serious risk involving remote, unauthenticated compromise.
The vulnerability was reported to Phoenix Contact on February 9, 2026. ZDI published technical details on July 30 and stated that firmware version 1.9.1 fixes the issue.
You should treat this vulnerability as a potential operational technology security issue, not simply as an equipment update. An attacker may be able to place modified firmware on a charging controller without first proving their identity. If successful, the attacker could gain control of the device and alter how charging infrastructure operates.
The immediate business risk is service interruption. Charging stations could become unavailable, behave unpredictably, or require emergency maintenance. For a fleet operator, that could delay vehicle dispatches. For a retailer, property manager, or parking operator, it could reduce customer access and create refund or service obligations.
A compromised controller may also provide a foothold for attacks against connected management systems or other operational technology. Depending on network design, attackers could target configuration data, charging records, backend connections, or systems used to monitor and administer multiple sites.
You may also face contractual, regulatory, and insurance consequences. A security incident involving payment-related systems, customer information, or critical transportation infrastructure could trigger notification duties, forensic costs, audit scrutiny, and questions about whether reasonable safeguards were in place.
The exposure is particularly significant when charging controllers are reachable from the public internet, placed on a shared business network, or managed through poorly protected remote-access services. Phoenix Contact describes the affected products as intended for closed industrial networks and recommends firewall protection.certvde
Regional Bank Workplace Charging: A regional bank operates charging stations in employee parking areas. An attacker compromises an exposed controller, interrupts charging availability, and uses the device as a starting point to investigate adjacent network resources. The bank must suspend remote administration while security teams determine whether corporate systems were affected.
Commercial Property Portfolio: A property management company maintains charging stations at several office and apartment locations. A firmware compromise causes inconsistent charging behavior and inaccurate station status information, resulting in tenant complaints, service credits, emergency technician visits, and reputational damage across multiple properties.
Fleet and Logistics Operator: A logistics company depends on overnight charging for delivery vehicles. Attackers disrupt charging before a scheduled dispatch period, forcing the company to reorganize routes, lease replacement vehicles, and pay overtime while the charging network is investigated and restored.
Public Charging Network: A smaller charging operator serves drivers across several communities. A compromised controller alters station behavior or prevents customers from completing sessions. Even if no customer data is stolen, the operator may face payment disputes, poor public reviews, lost revenue, and pressure from partners to demonstrate that every affected device has been secured.
If any item applies, identify the device owner and service provider, preserve relevant logs, restrict unnecessary network access, and begin remediation immediately.
Do not wait for a charging disruption to reveal an avoidable weakness. IntegSec can assess your exposure, validate segmentation and remote-access controls, and perform a penetration test designed around your operational technology environment. Contact IntegSec to turn CVE-2026-44104 from an uncertain business risk into a documented, actionable security plan.
CVE-2026-44104 is an improper cryptographic signature verification flaw, classified as CWE-347. The affected component is the firmware update process for the basemodule of Phoenix Contact CHARX SEC-3000, SEC-3050, SEC-3100, and SEC-3150 controllers. Firmware versions earlier than 1.9.1 are affected.certvde
The update process validates a CRC32 checksum but does not verify a trusted cryptographic signature. CRC32 can detect accidental corruption, but it does not establish authenticity because an attacker can calculate a valid checksum for modified content. The result is a firmware trust failure that may allow an unauthenticated attacker to install altered firmware and obtain complete control of the charging controller.
The attack is network-based and requires no authentication or user interaction according to the official CVSS 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The official score is 9.8, rated critical. NVD records CVSS 4.0 as 9.3 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.
The NVD reference is CVE-2026-44104. CERT VDE is the coordinating vulnerability authority, and ZDI reported the issue.
Version enumeration: Identify each controller by asset inventory, product label, management interface, or Phoenix Contact administrative tooling. Record the exact model and firmware version, then compare it with the vendor remediation threshold of firmware 1.9.1. Do not infer the version from the controller model alone.
Scanner signatures: Use a vulnerability scanner that supports CVE-2026-44104 and Phoenix Contact CHARX SEC3xxx firmware detection. Confirm that the scanner identifies the model and firmware rather than reporting only an exposed service. A credentialed or authenticated asset query is preferable where supported.
Log indicators: Review firmware update logs, administrative events, configuration changes, unexpected reboots, failed update attempts, and connections to unfamiliar hosts. Examine OCPP backend, MQTT, Modbus, firewall, and remote-access logs around suspicious events.
Behavioral anomalies: Investigate unexplained charging interruptions, altered charging-point configuration, inconsistent station status, unexpected changes to backend connections, and repeated reboots. Compare device configuration and firmware records with approved baselines.
Network indicators: Look for unauthorized inbound connections, unexpected firmware downloads, unusual traffic to charging-controller management services, and communication from charging devices to unapproved internet destinations. Treat direct internet exposure as a high-priority finding.
Testing should occur in an approved maintenance window. Security teams should avoid sending untrusted firmware or attempting exploitation against production charging equipment without written authorization and a recovery plan.