← Back to Feed CACHED · 2026-07-31 01:44:30 · CACHE_KEY CVE-2026-44095
CVE-2026-44095 · CWE-78 · Disclosed 2026-07-30

Phoenix Contact CHARX SEC Network Configuration Script OS Command Injection Local Privilege Escalation

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Local priv-esc on an OT charging controller — narrow access path, but OT blast radius keeps it HIGH"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Obtain local shell on the CHARX controller

The attacker must first get a low-privileged shell on the embedded Linux OS of the charging controller. This can happen via physical console access, SSH with known or default credentials, or — far more realistically — by chaining one of the remote CVEs in VDE-2026-008 (e.g., CVE-2026-7849, CVSS 9.8 unauthenticated command injection). The device runs custom Cython-based web services on ports 5001 and 9999.
Conditions required:
  • Local or chained remote access to the CHARX controller
  • Valid low-privileged user session (e.g., charx-web)
Where this breaks in practice:
  • 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
Detection/coverage: Network-level: anomalous SSH or reverse-shell traffic from charging controller IP. Host-level: limited — most CHARX deployments lack EDR or host-based IDS.
STEP 02

Inject OS command into network configuration script

The attacker crafts a malicious input — likely a specially formed network parameter value containing shell metacharacters — that gets passed unsanitized to the network configuration script. Because the script lacks proper input neutralization (CWE-78), the injected payload is concatenated directly into a command string. No user interaction is required.
Conditions required:
  • Ability to write or influence parameters consumed by the network config script
  • Low-privilege user context sufficient to trigger the script
Where this breaks in practice:
  • 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
STEP 03

Script executes payload as root

The network configuration script runs with root privileges — standard for network-management scripts on embedded Linux. The injected command executes in root context, giving the attacker full control over the charging controller: read/write firmware, modify OCPP backend configuration, alter charging behavior, pivot to adjacent network devices via the controller's Ethernet or cellular interfaces.
Conditions required:
  • Successful injection from step 2
Where this breaks in practice:
  • Scope is limited to the individual charging controller (CVSS Scope: Unchanged)
  • Lateral movement requires additional vulnerabilities or misconfigurations on adjacent OT network
Detection/coverage: Post-exploitation: unexpected processes, modified config files, or outbound connections from the controller. SIEM correlation of OCPP backend anomalies may surface compromise indirectly.
03 · Compensating Control

1
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.
2
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.
3
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.
4
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.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNot observed. Not listed in CISA KEV. No known campaigns targeting this specific CVE as of 2026-07-31.
Proof-of-conceptNone 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).
EPSS0.00232 — bottom ~10th percentile. Very low predicted exploitation probability in the next 30 days.
KEV statusNot listed as of 2026-07-31.
CVSS vectorCVSS: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 versionsPhoenix Contact CHARX SEC-3000, SEC-3050, SEC-3100, SEC-3150 — firmware 1.0.0 through < 1.9.1
Fixed versionFirmware 1.9.1 — available no later than August 12, 2026
Exposure dataNo 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 date2026-07-30 via CERT@VDE advisory VDE-2026-008
Reporting researcher/orgCoordinated by CERT@VDE; research lineage includes NCC Group (Pwn2Own Automotive). Specific reporter for CVE-2026-44095 not individually credited.

Sources.

  1. NVD — CVE-2026-44095
  2. CERT@VDE Advisory VDE-2026-008
  3. Canadian Centre for Cyber Security — AV26-546
  4. VicOne — Pwn2Own Automotive CHARX SEC-3100 RCE Analysis
  5. runZero — Finding Affected Phoenix Contact Assets
  6. SecurityWeek — ICS Patch Tuesday: Phoenix Contact Fixes
  7. Phoenix Contact PSIRT
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.0/10)

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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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