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

A privilege escalation vulnerability in a script used for network configuration

ASSESSED — NOISGATE V0.5
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 · 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.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.0/10)

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.

HIGH Vulnerability mechanics and affected version range
MEDIUM Real-world exposure and installed base size
LOW Exploitation likelihood in isolation (no PoC, no known chaining observed)

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.

05 · Compensating Control

What to do — in priority order.

  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.
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
07 · Bottom Line

If you remember one thing.

TL;DR
If you operate Phoenix Contact CHARX SEC charging controllers, this CVE is part of a 22-vulnerability advisory that includes five CRITICAL remote-entry flaws — treat the entire advisory as a unit. Per the noisgate mitigation SLA for HIGH, deploy compensating controls (network isolation of all CHARX controllers behind a dedicated OT firewall, account hardening) within 30 days. Per the noisgate remediation SLA, apply firmware 1.9.1 within 180 days — but realistically, target mid-August when Phoenix Contact releases it (ETA August 12, 2026) because the companion CRITICAL CVEs in this advisory warrant urgency beyond what this single HIGH CVE demands. If your CHARX controllers are reachable from any untrusted network today, isolate them this week — the remote CVEs in the same advisory are far more dangerous than this local priv-esc alone.

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
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.