ctipilot.ch

Phoenix Contact CHARX SEC-3xxx — MQTT broker reachable without authentication, protected from external access only by the device firewall (CWE-306); CVSS 3.1 9.8

cve · CVE-2026-44090 single-source

Coverage timeline
1
first 2026-08-02 → last 2026-08-02
Peak priority
high
1 high
Sources cited
1
1 hosts
Sections touched
1
trending-vulnerabilities
Co-occurring entities
4
see Related entities below
ATT&CK techniques
2
pinned v19.1 · see below

Hunting pivots

ATT&CK techniques
Affected products
Phoenix Contact CHARX SEC-3000Phoenix Contact CHARX SEC-3050Phoenix Contact CHARX SEC-3100Phoenix Contact CHARX SEC-3150

ATT&CK techniques

2 techniques observed across 1 entry — derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.1 · compare on the matrix · Navigator layer (JSON)

Initial Access TA0001

T1190Exploit Public-Facing Application×1

Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.

Evidence: 2026-08-02/phoenix-contact-charx-sec-3xxx-unauth-root-no-firmware-yet · ATT&CK page ↗

Persistence TA0003

T1542.001Pre-OS Boot: System Firmware×1

Adversaries may modify system firmware to persist on systems.The BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) or Extensible Firmware Interface (EFI) are examples of system firmware that operate as the software interface between the operating system and hardware of a computer.

Evidence: 2026-08-02/phoenix-contact-charx-sec-3xxx-unauth-root-no-firmware-yet · ATT&CK page ↗

Stealth TA0005

T1542.001Pre-OS Boot: System Firmware×1

Adversaries may modify system firmware to persist on systems.The BIOS (Basic Input/Output System) and The Unified Extensible Firmware Interface (UEFI) or Extensible Firmware Interface (EFI) are examples of system firmware that operate as the software interface between the operating system and hardware of a computer.

Evidence: 2026-08-02/phoenix-contact-charx-sec-3xxx-unauth-root-no-firmware-yet · ATT&CK page ↗

Story timeline

  1. 2026-08-02CVE-2026-7849 and 19 more — Phoenix Contact CHARX SEC-3xxx EV charging controllers: unauthenticated command injection as root, unsigned firmware updates, and no fix released at disclosure
    trending-vulnerabilitiesCERT@VDE publishes 20 CVEs in Phoenix Contact EV charging controllers with the fixing firmware unreleased — segmentation is the only control to 12 August

Where this entity is cited

  • trending-vulnerabilities1

Source distribution

  • certvde.com1 (100%)

Co-occurring entities

Derived — referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Entries about Phoenix Contact CHARX SEC-3xxx — MQTT broker reachable without authentication, protected from external access only by the device firewall (CWE-306); CVSS 3.1 9.8 (1)

2026-08-02 · view entry permalink →

CVE-2026-7849 and 19 more — Phoenix Contact CHARX SEC-3xxx EV charging controllers: unauthenticated command injection as root, unsigned firmware updates, and no fix released at disclosure

This is a recovery published by the 2026-08-02 weekly quality audit: the advisory landed inside the audit window and no entry covered it.

An advisory that lands before its own fix is unusual enough to change the defender's task from patching to containment, and this one lands with five unauthenticated CVSS 9.8 issues. The most direct is CVE-2026-7849: "Due to improper neutralization of special elements, an unauthenticated remote attacker is able to inject a command into the system configuration which is subsequently executed as root" (CERT@VDE, 2026-07-30) — no credential, no interaction, root on the controller. CVE-2026-44104 is the one with the longest tail: the basemodule firmware update process validates a "CRC32 checksum without cryptographic signature verification", and "This allows an unauthenticated remote attacker to install a modified firmware, resulting in full system compromise." A CRC32 is an accidental-corruption check, not an authenticity check, and firmware an attacker chose survives every subsequent reboot and legitimate update cycle — which is why this flaw outlives the patch for any device compromised before 1.9.1 is applied.

Two more are about services that were never meant to be reachable. CVE-2026-44101 removes authentication from the CHARX OCPP Agent, the component that speaks the Open Charge Point Protocol to the operator's backend: a remote attacker can reconfigure which backend the charge point talks to, which the advisory records as leading to denial of service and disclosure of confidential data. CVE-2026-44090 leaves the MQTT broker reachable without authentication, "protected from external access by a firewall" and nothing else. And CVE-2026-44108 undermines exactly that firewall: "Due to a flaw in the execution order of scripts during shutdown, the firewall is terminated prematurely during system shutdown. This creates a temporary window in which internal services may become externally accessible, potentially allowing an unauthenticated remote attacker to connect to these services, resulting in full system compromise." The vendor's stated mitigation is a firewall, and one of the twenty flaws is that the firewall goes away during every shutdown — so the mitigation has to be enforced by the network, not by the device.

The constituency nexus is direct rather than analogical. Public EV charging sits across two of the profiled sectors at once — energy, because charge points are grid-edge load, and transport, because municipal and fleet charging is increasingly run by cantonal and communal operators or their contractors. Phoenix Contact is a German industrial-automation supplier with a wide European installed base, and CHARX SEC controllers are the charge-point control units rather than back-office software, so the affected devices are physically distributed, frequently connected over operator or mobile networks, and rarely in a mature patch cycle. Phoenix Contact's own framing is that the "charging controllers are designed and developed for the use in closed industrial networks" — which is a statement about intended deployment, and worth checking against how they actually got deployed.

Triage: these devices produce very little telemetry, so the discriminators live on the network rather than the host. Legitimate OCPP traffic goes from the charge point to one known operator backend on a stable endpoint; a reconfiguration attack shows up as the same device suddenly establishing OCPP or WebSocket sessions to a different destination, which is a single-field comparison against an expected-backend list and needs no deep inspection. Legitimate MQTT on these units is local to the charging installation; an MQTT connection sourced from outside the charging VLAN is not a tuning question. And an unscheduled reboot followed by a firmware version that does not match the change record is the manifestation of the unsigned-update flaw — worth an inventory-diff job rather than an alert rule, since a charge point that quietly changed firmware version is the observable that matters and no log on the device will report it.

Due to improper neutralization of special elements, an unauthenticated remote attacker is able to inject a command into the system configuration which is subsequently executed as root.

The updated firmware will be made available as soon as possible, but no later than August 12, 2026.

Due to a flaw in the execution order of scripts during shutdown, the firewall is terminated prematurely during system shutdown. This creates a temporary window in which internal services may become externally accessible, potentially allowing an unauthenticated remote attacker to connect to these services, resulting in full system compromise.

CERT@VDE 2026-07-30
vulnerability02 Aug 13:55Zsingle-sourceOpen finding ↗
Sources: CERT@VDE