On July 30, 2026, advisory ZDI-26-518 disclosed a vulnerability in the MQTT service of Phoenix Contact CHARX SEC-3150 devices — EV charging stations deployed across critical infrastructure. The flaw, tracked as CVE-2026-44091, allows an unauthenticated, network-adjacent attacker to manipulate the MQTT broker into targeting unauthorized internal resources. The result is a classic SSRF scenario that, when chained with other vulnerabilities, can lead to remote code execution.
- Vulnerability ZDI-26-518 affects the MQTT broker in Phoenix Contact CHARX SEC-3150 devices for EV charging infrastructure
- An unauthenticated, network-adjacent attacker exploits missing URI validation to force requests toward internal resources
- Isolated SSRF becomes full RCE only when chained with additional vulnerabilities, in the context of the user-app account
- The official CVE Record shows conflicting scores: CVSS 3.1 at 9.1 CRITICAL and CVSS 4.0 at 8.8 HIGH, while the published ZDI list reports 6.3
- Patched firmware v1.9.1 is slated for August 12, 2026, with initial vendor disclosure dating back to February 9, 2026
The Mechanism: When the MQTT Broker Doesn't Check Where It Talks
The specific flaw resides in the MQTT service of the CHARX SEC-3150 firmware. According to the ZDI advisory, "the issue results from the lack of proper validation of a URI prior to accessing resources." The broker, tasked with managing messages between IoT/OT devices, accepts URIs without verifying their legitimate destination. This omission lets an attacker redirect internal traffic toward endpoints that should never be reachable from the outside.
The vector is technically a Server-Side Request Forgery (SSRF). It is not a direct device compromise, but a reversal of the communication flow. The attacker tricks the server into acting as an unwitting proxy, probing ports, services, and administrative interfaces normally isolated in the internal network segment. The required network-adjacent position reduces the attack surface compared to internet exposure, but does not eliminate it: poorly segmented corporate networks, guest Wi-Fi access, or prior compromise of nearby endpoints still open the door.
From SSRF to RCE: The Chain That Doesn't Depend on a Single Flaw
The ZDI advisory precisely defines the limits of the isolated vulnerability. The verbatim quote is unambiguous: "An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the user-app account." The SSRF is the first link, not the whole chain. Achieving full RCE requires chaining CVE-2026-44091 with additional flaws not detailed in the public dossier.
This distinction has concrete operational consequences. A defender cannot merely monitor for direct SSRF attempts as if they were complete exploits, nor can they downplay the risk. SSRF as an internal access vector remains a powerful tool for reconnaissance, MQTT configuration manipulation, and preparation of multi-stage attacks. In the context of EV charging infrastructure, where service availability and integrity are critical, even partial broker access can translate into operational disruption or alteration of charging parameters.
"This vulnerability allows network-adjacent attackers to access internal resources on affected installations of Phoenix Contact CHARX SEC-3150 devices. Authentication is not required to exploit this vulnerability." — ZDI Advisory ZDI-26-518
The Conflicting Numbers: Why the CVSS Score Swings Between 6.3 and 9.1
The dossier presents a severity scoring discrepancy that cannot be ignored. The published ZDI list assigns CVE-2026-44091 a CVSS of 6.3, a value that would classify the vulnerability as MEDIUM. The official CVE Record instead reports two metrics: CVSS 3.1 at 9.1 CRITICAL with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, and CVSS 4.0 at 8.8 HIGH.
Interpreting this divergence requires caution. The CVSS 3.1 vector with Network Access Vector (AV:N) and Privileges Required None (PR:N) describes a flaw reachable without authentication over the network, with high impact on integrity and availability. The ZDI score of 6.3 may reflect a more conservative assessment, perhaps weighted on the need for network-adjacent access or the complexity of the RCE chain. The source does not clarify which criterion is correct, and the dossier explicitly flags this uncertainty among its limits. For the reader, the practical indication is that CVE-2026-44091 falls into a high-risk band, with version 3.1 slightly overstating severity relative to operational reality and the ZDI version potentially understating it.
Timeline and Fix: Five Months from Report to Patch
The documented timeline shows responsible but not rapid disclosure. The vulnerability was reported to Phoenix Contact on February 9, 2026. Coordinated publication occurred on July 30, 2026, with patched firmware v1.9.1 slated for August 12, 2026. This interval of nearly six months between report and patch availability, plus an additional near-two-week gap between advisory and fix, places the device in a prolonged exposure window.
The Pwn2Own context, explicitly cited in the advisory title, confirms the flaw was demonstrated in competition. This implies the existence of working proof-of-concept exploits, even if not public. The Zero Day Initiative competition, organized by Trend Micro, rewards researchers for exploits against real targets under controlled conditions. The presence of researcher Giuseppe Calì, and a second participant identified only by cryptographic hash, completes the picture of a shared but not yet fully attributed discovery.
What to Do Now
- Verify the presence of Phoenix Contact CHARX SEC-3150 devices in your installed base and identify the running firmware version
- Plan the upgrade to firmware v1.9.1 as soon as it becomes available on August 12, 2026, prioritizing devices exposed to network segments with uncontrolled access
- Isolate EV charging infrastructure MQTT brokers in dedicated VLANs, limiting network-adjacent visibility to authorized devices
- Monitor MQTT service logs for URI request anomalies, with particular attention to unexpected internal destinations outside standard operational flows
Why This Flaw Tells a Broader Story About Industrial IoT
Vulnerability ZDI-26-518 is not an isolated case of faulty implementation, but a symptom of structural misalignment. Protocols like MQTT, CoAP, and their peers were designed for resource-constrained environments, where payload lightness trumps control completeness. When these protocols migrate to critical infrastructure — EV chargers, energy management systems, water distribution networks — that same lightness becomes a liability.
The electric charging sector is expanding at an accelerated pace, with attack surfaces growing faster than hardening expertise distributed among network operators, installers, and fleet managers. Phoenix Contact is an established vendor in industrial automation, and the CHARX SEC-3150 represents a professional-grade product. If even here input validation in the MQTT broker is missing, the problem likely reproduces with greater probability in consumer-grade or less-scrutinized white-label devices.
The advisory documents no in-the-wild exploits or active campaigns, but the Pwn2Own context and coordinated publication expose the vulnerability to a community of researchers and potential attackers. The window between disclosure and patch is the moment of maximum uncertainty: long enough for exploit diffusion, too short for definitive mitigation.
Sources
Information verified against cited sources and current as of publication.