Which versions of CHARX SEC are affected by EUVD-2026-51025?

Phoenix Contact CHARX SEC electric-vehicle charging controllers contain a critical authentication bypass in their embedded MQTT broker that allows remote attackers to gain complete operational…. A patch is available.

How to fix or mitigate EUVD-2026-51025?

Within 24 hours, identify all Phoenix Contact CHARX SEC charging controllers on the network and assess network accessibility to the MQTT broker service. Within 7 days, apply the patch made available by Phoenix Contact to all affected devices, prioritizing those with highest network exposure. By day 30, validate patch deployment across all systems and implement network-level access controls to restrict MQTT broker connectivity.

CHARX SEC EUVD-2026-51025

Q: What is the CVSS score of EUVD-2026-51025?

EUVD-2026-51025 has a CVSS 4.0 base score of 9.3 (Critical). CVSS 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.4%.

| CVE-2026-44090 CRITICAL

Missing Authentication for Critical Function (CWE-306)

2026-07-30 info@cert.vde.com

GHSA-9h9r-3q9w-h7vj

Authentication Bypass

9.3

CVSS 4.0 · Vendor: cert

Severity by source

Vendor (cert) PRIMARY

9.3 CRITICAL

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.8 CRITICAL

Unauthenticated MQTT broker reachable over the network with no user interaction gives AV:N/AC:L/PR:N/UI:N; full device compromise yields C:H/I:H/A:H, with firewall reachability a deployment caveat.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (cert).

CVSS VectorVendor: cert

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 30, 2026 - 08:38 vuln.today

Patch available

Jul 30, 2026 - 08:03 EUVD

CVE Published

Jul 30, 2026 - 07:16 cve.org

CRITICAL 9.3

DescriptionCVE.org

Due to missing authentication, an unauthenticated remote attacker may access the MQTT broker, which is only protected from external access by a firewall. This may lead to the device being fully compromised.

AnalysisAI

Missing authentication on the MQTT broker embedded in Phoenix Contact CHARX SEC electric-vehicle charging controllers allows a remote attacker who can reach the broker to take full control of the device. Because the broker enforces no authentication and relies solely on an external firewall for protection, any actor able to route to the MQTT service can issue broker commands leading to complete compromise. Rated CVSS 4.0 9.3 (critical); no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

The affected component is the MQTT broker running on CHARX SEC-3000/3050/3100/3150 AC charging controllers, devices used to manage EV charging sessions and OCPP/backend communication. MQTT is a lightweight publish/subscribe messaging protocol commonly used for device telemetry and command-and-control; brokers can and should enforce username/password or TLS client-certificate authentication. This flaw is classified as CWE-306 (Missing Authentication for Critical Function): the broker exposes control functionality without verifying the identity of connecting clients, so anyone who can open a TCP session to the broker port is treated as a trusted client. The vendor advisory VDE-2026-008 (published via CERT@VDE) tracks the issue, also cataloged as EUVD-2026-51025.

RemediationAI

Vendor-released patch: 1.9.1 - upgrade all affected CHARX SEC-3000/3050/3100/3150 controllers to firmware 1.9.1 or later, as documented in advisory VDE-2026-008 (https://www.certvde.com/en/advisories/VDE-2026-008/). Until patching is possible, the primary compensating control is to keep and tighten the network firewall that isolates the MQTT broker: restrict inbound access to the broker's port so only explicitly trusted management hosts can connect, and place charging controllers on a dedicated, segmented VLAN with no direct internet or general-LAN reachability. The trade-off is operational - overly aggressive filtering may block legitimate backend/OCPP or management traffic, so validate that authorized systems retain access after locking down the broker.