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.