CVE-2026-44104: Unsigned Firmware Update Vulnerability - What It Means for Your Business and How to Respond

Introduction

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.

S1 — Background & History

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.

S2 — What This Means for Your Business

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

S3 — Real-World Examples

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.

S4 — Am I Affected?

• You are running a Phoenix Contact CHARX SEC-3000, SEC-3050, SEC-3100, or SEC-3150 charging controller.
• Your affected controller is running firmware earlier than version 1.9.1.
• Your charging controller is connected to the public internet, a shared corporate network, or a remote management path without strong segmentation.
• Your organization uses Open Charge Point Protocol, Message Queuing Telemetry Transport, Modbus, or another management connection associated with the charging environment.
• You cannot confirm the firmware version, network exposure, firewall rules, or recent administrative activity for the controller.
• You have observed unexpected reboots, unexplained charging interruptions, configuration changes, unusual outbound connections, or firmware update activity.
• You manage charging infrastructure through a service provider and do not have written confirmation that the affected devices were updated to firmware 1.9.1.

If any item applies, identify the device owner and service provider, preserve relevant logs, restrict unnecessary network access, and begin remediation immediately.

Key Takeaways

• CVE-2026-44104 is a critical vulnerability affecting Phoenix Contact CHARX SEC3xxx charging controllers running firmware earlier than version 1.9.1.
• You could face charging outages, operational disruption, recovery costs, compliance concerns, and reputational harm if an affected controller is compromised.
• You should prioritize devices reachable from the internet or connected to shared business and operational networks.
• You should confirm firmware versions, review network exposure, preserve evidence, and coordinate remediation with your charging infrastructure provider.
• You should update affected controllers to firmware 1.9.1 and validate the surrounding environment after deployment.certvde

Call to Action

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.

Technical Appendix

A — Technical Analysis

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.

B — Detection & Verification

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.

C — Mitigation & Remediation

1. Immediate, 0–24 hours: Identify all CHARX SEC3xxx devices and determine their firmware versions. Restrict direct internet access, place controllers in a dedicated operational technology network, and allow only required management and backend communications through a firewall. Preserve logs and configuration backups before making changes. Phoenix Contact recommends using these controllers in closed industrial networks protected by a suitable firewall.certvde
2. Short-term, 1–7 days: Obtain the official Phoenix Contact firmware release and update every affected controller to firmware 1.9.1 or later, following the vendor’s installation procedure. The vendor states that firmware 1.9.1 addresses the reported vulnerabilities. Verify the resulting version on each device, test charging operations, and confirm that backend communication remains restricted to approved systems.certvde
3. Interim protection for systems that cannot be patched immediately: Keep the controller off the public internet, block unnecessary inbound traffic, restrict administrative access to approved management hosts, and use tightly controlled jump hosts for maintenance. Disable unused protocols and services where operationally safe. Increase monitoring for firmware activity, configuration changes, reboots, and unexpected network connections. These measures reduce exposure but do not correct the missing signature verification.
4. Long-term, ongoing: Establish an asset inventory for charging infrastructure, require signed firmware and documented vendor provenance, and add firmware verification to change management. Segment charging equipment from corporate information systems and limit east-west communication between sites. Conduct a targeted penetration test after patching to validate that remote services, firewall rules, backend integrations, and recovery procedures do not create an alternate path to compromise.

D — Best Practices

• Maintain a current inventory of every charging controller, model, firmware version, physical location, owner, and network connection.
• Permit firmware updates only through approved vendor channels and verify cryptographic authenticity before installation.
• Place charging controllers in segmented operational technology networks instead of shared corporate or public networks.
• Monitor OCPP, MQTT, Modbus, firewall, and administrative logs for unauthorized access, configuration changes, firmware activity, and unexpected reboots.
• Test restoration procedures, configuration backups, and controlled firmware rollback plans without relying on unverified firmware images.