Which versions of CHARX SEC are affected by CVE-2026-44092?

Phoenix Contact's CHARX SEC electric-vehicle charging controllers (series 3000/3050/3100/3150) contain a remote input validation flaw allowing unauthenticated attackers to inject malicious data…. A patch is available.

How to fix or mitigate CVE-2026-44092?

Within 24 hours, conduct a complete inventory of all CHARX SEC charging controllers in your environment and identify units running firmware versions 1.0.0 through 1.9.0; document MQTT network connectivity and update dependencies. Within 7 days, initiate staged deployment of firmware 1.9.1, starting with mission-critical charging sites and validating full operational functionality after each upgrade. Within 30 days, verify that firmware 1.9.1 is deployed across all affected CHARX SEC units and confirm no vulnerable instances remain in production.

CHARX SEC CVE-2026-44092

Q: What is the CVSS score of CVE-2026-44092?

CVE-2026-44092 has a CVSS 4.0 base score of 8.8 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/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%.

EUVD-2026-51027 HIGH

Improper Neutralization of CRLF Sequences ('CRLF Injection') (CWE-93)

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

GHSA-hf79-46vv-6v3g

Code Injection Red Hat

8.8

CVSS 4.0 · Vendor: cert

Severity by source

Vendor (cert) PRIMARY

8.8 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/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.1 CRITICAL

Unauthenticated network MQTT injection with no interaction (AV:N/AC:L/PR:N/UI:N); integrity and availability high, confidentiality none per described impact.

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

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

Red Hat

9.1 CRITICAL

qualitative

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:37 vuln.today

Patch available

Jul 30, 2026 - 08:03 EUVD

CVE Published

Jul 30, 2026 - 07:16 cve.org

HIGH 8.8

DescriptionCVE.org

An unauthenticated remote attacker can inject malicious input into the ModbusServer application because it does not validate the input it fetches from MQTT. This may lead to integrity and availability loss.

AnalysisAI

Improper input neutralization in Phoenix Contact CHARX SEC electric-vehicle charging controllers lets a remote, unauthenticated attacker inject malicious data through MQTT that the bundled ModbusServer application processes without validation, corrupting Modbus data and disrupting service. All CHARX SEC-3000/3050/3100/3150 units running firmware 1.0.0 through 1.9.0 are affected, with impact limited to integrity and availability (no data disclosure). No public exploit identified at time of analysis; the flaw was coordinated-disclosure reported through CERT@VDE and a fixed firmware (1.9.1) is available.

Technical ContextAI

The affected devices are CHARX SEC series charge controllers used to manage AC EV charging stations, exposing an MQTT interface and an embedded ModbusServer that bridges MQTT-delivered values into the Modbus/TCP register space used by site controllers and SCADA. The root cause is CWE-93 (Improper Neutralization of CRLF Sequences) combined with the vendor's 'Code Injection' tagging: values received over MQTT are passed into the ModbusServer without sanitizing control/separator sequences, so an attacker-supplied payload can alter how the server parses or frames subsequent data. Because MQTT topics are frequently broker-relayed and unauthenticated in OT deployments, tainted input reaches the Modbus handling logic directly.

RemediationAI

Vendor-released patch: update affected CHARX SEC-3000/3050/3100/3150 devices to firmware 1.9.1 or later, which is the fixed release identified in the EUVD affected-version range and the CERT@VDE advisory VDE-2026-008 (https://www.certvde.com/en/advisories/VDE-2026-008/). Where immediate patching is not possible, restrict reachability of the MQTT interface: place the broker and charge controllers on an isolated OT/management VLAN, block external access to the MQTT port (typically 1883/8883) at the perimeter, and enforce authentication/TLS and topic ACLs on the broker so only trusted publishers can send values consumed by ModbusServer - the trade-off is that any legitimate remote MQTT integrations must be re-onboarded through the authenticated path. Additionally limit Modbus/TCP (502) exposure to known site controllers; the side effect is reduced ad-hoc monitoring access.