A misquoted shell variable in a network-setup script hands root to anyone already inside an EV charging brain
CVE-2026-44095 is an OS command injection (CWE-78) in a network configuration script shipped on Phoenix Contact CHARX SEC-3000, SEC-3050, SEC-3100, and SEC-3150 EV charging controllers running firmware versions 1.0.0 through 1.9.0. A low-privileged local user — such as the charx-web service account — can inject arbitrary commands into the script, which the system executes as root. The result is full device compromise: confidentiality, integrity, and availability. The fix is firmware 1.9.1, expected no later than August 12, 2026.
The vendor's HIGH / 7.8 rating is honest and nearly right. This CVE is one of 22 flaws disclosed in advisory VDE-2026-008, several of which are unauthenticated remote RCE at CVSS 9.8. CVE-2026-44095 by itself requires local access, which is hard to get on an embedded Linux appliance — but it becomes trivially chainable with any of the five CRITICAL remote-entry CVEs in the same advisory. On its own the 7.8 is slightly generous because local shell access to a purpose-built controller is not the same as local access on a general-purpose server; noisgate adjusts to 7.0 while respecting the OT floor.
3 steps from start to impact.
Obtain local shell on the CHARX controller
- Local or chained remote access to the CHARX controller
- Valid low-privileged user session (e.g.,
charx-web)
- Device is an embedded appliance, not a general-purpose host — no interactive user logins by design
- Vendor recommends deployment in closed industrial networks behind a firewall
- Physical access typically requires site entry to the charging station cabinet
Inject OS command into network configuration script
- Ability to write or influence parameters consumed by the network config script
- Low-privilege user context sufficient to trigger the script
- Requires knowledge of the specific script path and parameter format on CHARX firmware
- No public PoC or exploit code is available as of 2026-07-31
Script executes payload as root
- Successful injection from step 2
- Scope is limited to the individual charging controller (CVSS Scope: Unchanged)
- Lateral movement requires additional vulnerabilities or misconfigurations on adjacent OT network
- IT-focused EDR/AV — CHARX SEC controllers run embedded Linux; standard enterprise EDR agents (CrowdStrike, SentinelOne, Defender for Endpoint) cannot be installed on these devices. Do not assume your endpoint protection covers this attack surface.
- Web Application Firewalls (WAF) — the vulnerable script is a local OS-level network configuration script, not a web endpoint. A WAF in front of the controller's web services will not intercept local command injection.
- TLS/certificate hardening alone — while important for OCPP and MQTT, TLS does not prevent a locally authenticated user from exploiting a shell injection in a system script.
The supporting signals.
| In-the-wild exploitation | Not observed. Not listed in CISA KEV. No known campaigns targeting this specific CVE as of 2026-07-31. |
|---|---|
| Proof-of-concept | None public. No exploit code on GitHub, Exploit-DB, or ZDI advisories for this specific CVE. The broader CHARX attack surface was demonstrated at Pwn2Own Automotive 2024 by McCaulay Hudson and Alex Plaskett (NCC Group). |
| EPSS | 0.00232 — bottom ~10th percentile. Very low predicted exploitation probability in the next 30 days. |
| KEV status | Not listed as of 2026-07-31. |
| CVSS vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — Local access, low complexity, low privileges, no user interaction, unchanged scope. Full CIA impact on the device. |
| Affected versions | Phoenix Contact CHARX SEC-3000, SEC-3050, SEC-3100, SEC-3150 — firmware 1.0.0 through < 1.9.1 |
| Fixed version | Firmware 1.9.1 — available no later than August 12, 2026 |
| Exposure data | No Shodan/Censys/GreyNoise data specific to CVE-2026-44095. CHARX controllers have Ethernet and 4G/2G interfaces. Vendor states devices are "designed for closed industrial networks" — internet exposure expected to be minimal. |
| Disclosure date | 2026-07-30 via CERT@VDE advisory VDE-2026-008 |
| Reporting researcher/org | Coordinated by CERT@VDE; research lineage includes NCC Group (Pwn2Own Automotive). Specific reporter for CVE-2026-44095 not individually credited. |
Sources.
Why this verdict
- Local access friction: AV:L means the attacker must already have a shell on the embedded Linux controller. This is not a general-purpose server with user logins — gaining that foothold requires either physical cabinet access or chaining a separate remote CVE.
- No public PoC or exploitation: EPSS is 0.00232, no KEV listing, no known campaigns, and no public exploit code. The attack is currently theoretical.
- Role multiplier (OT/ICS): The CHARX SEC is an EV charging controller — an OT device by definition. Root compromise enables modification of charging parameters, OCPP backend reconfiguration, and potential safety impact. ≥90% of CHARX SEC installs occupy this OT role by definition. The chain succeeds in this role and the blast radius is operational/safety impact per charging station + potential lateral pivot via Ethernet/cellular. This floors the verdict at HIGH.
- Advisory context amplifies risk: This CVE sits alongside 5 CRITICAL remote-entry CVEs (CVSS 9.8) in the same VDE-2026-008 advisory. In practice, CVE-2026-44095 is most dangerous as a chain step after remote compromise — making it a reliable priv-esc primitive once an attacker lands via CVE-2026-7849 or similar.
Why not higher?
CRITICAL would require either unauthenticated remote access (this is local-only) or fleet-scale blast radius from a single exploitation. The Scope is Unchanged — compromise is contained to the individual controller. While chaining with remote CVEs is plausible, the chain's entry-point CVEs are the ones that should carry the CRITICAL rating (and they do, at 9.8). Rating this local priv-esc step as CRITICAL would double-count the remote entry risk.
Why not lower?
MEDIUM would ignore the OT role floor. Root on an EV charging controller is not equivalent to root on a dev sandbox — it controls physical infrastructure and safety-relevant charging behavior. The low complexity (AC:L) and lack of user interaction (UI:N) mean exploitation is reliable once the local prerequisite is met. The presence of five remote-entry CVEs in the same advisory makes the local-access prerequisite less protective than it appears in isolation.
Crowdsourced verification payload.
Run this script on the CHARX SEC controller itself via SSH or serial console as any user. Invoke with: bash check_cve_2026_44095.sh. No special privileges required — it only reads the firmware version string.
#!/bin/bash
# check_cve_2026_44095.sh
# Checks if Phoenix Contact CHARX SEC firmware is vulnerable to CVE-2026-44095
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
FIXED_VERSION="1.9.1"
# Try common firmware version file locations on CHARX embedded Linux
FW_VERSION=""
for f in /etc/firmware_version /etc/charx_version /etc/version /data/charx-system-config/version; do
if [ -f "$f" ]; then
FW_VERSION=$(cat "$f" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+'| head -1)
break
fi
done
# Fallback: try charx CLI if available
if [ -z "$FW_VERSION" ] && command -v charx-info &>/dev/null; then
FW_VERSION=$(charx-info --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
fi
if [ -z "$FW_VERSION" ]; then
echo "UNKNOWN - Could not determine firmware version. Verify manually."
exit 2
fi
echo "Detected firmware version: $FW_VERSION"
echo "Fixed version: $FIXED_VERSION"
# Compare versions
version_gte() {
printf '%s\n%s' "$1" "$2" | sort -V | head -1 | grep -qx "$2"
}
if version_gte "$FW_VERSION" "$FIXED_VERSION"; then
echo "PATCHED - Firmware $FW_VERSION >= $FIXED_VERSION"
exit 0
else
echo "VULNERABLE - Firmware $FW_VERSION < $FIXED_VERSION (CVE-2026-44095)"
exit 1
fi