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
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. |
noisgate verdict.
The single most decisive factor is the OT/ICS role floor: the CHARX SEC controllers are operational-technology charging infrastructure where root compromise can alter physical charging behavior and safety-relevant configurations, preventing any downgrade below HIGH. The 0.8-point reduction from the vendor's 7.8 reflects the compounding friction of requiring local shell access to a purpose-built embedded appliance that should never be internet-facing.
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.
What to do — in priority order.
- Network-isolate all CHARX SEC controllers behind a dedicated OT firewall — The vendor explicitly states these devices are designed for closed networks. Enforce this by placing all CHARX controllers on a dedicated VLAN with no inbound access from IT networks or the internet. This neutralizes the remote-entry CVEs that make this local priv-esc chainable. Deploy within 30 days per the noisgate mitigation SLA for HIGH.
- Restrict and audit local accounts on the controller — Remove or disable any unnecessary local user accounts. Change default credentials if any exist. Monitor SSH access logs (if available) for anomalous logins. This raises the bar for the PR:L prerequisite.
- Monitor OCPP backend for configuration anomalies — If the controller's OCPP backend connection changes unexpectedly, or charging parameters are modified outside maintenance windows, treat it as a compromise indicator. This provides indirect detection of post-exploitation activity.
- Apply firmware 1.9.1 as soon as available (ETA: August 12, 2026) — This is the definitive fix for all 22 CVEs in VDE-2026-008. Plan a maintenance window for mid-August. Test on a non-production controller first if possible.
- 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.
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
fiIf you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.