Due to improper neutralization of special elements

CVE-2026-7849 is a pre-authentication command injection in the SCM component of Phoenix Contact CHARX SEC-3xxx series EV charging controllers (models SEC-3000, SEC-3050, SEC-3100, SEC-3150). All firmware versions prior to 1.9.1 are affected. An unauthenticated attacker who can reach the controller over the network can inject OS commands via the idledisconnect parameter, and those commands execute as root. This is one of nine vulnerabilities disclosed on 2026-07-30 via INCIBE/CERT@VDE coordination, three of which are rated critical.

Phoenix Contact's CRITICAL 9.8 rating is technically defensible for the device itself — AV:N/AC:L/PR:N/UI:N with full CIA impact at root is textbook 9.8 territory. However, for enterprise patch prioritization the rating overestimates *reachable* risk. These controllers are embedded Linux appliances deployed inside charging station enclosures, typically behind site LANs or cellular management gateways. They are not general-purpose servers; they don't hold AD credentials or backup catalogs. The blast radius per device is limited to the charging station and its local network segment. That said, these are OT/ICS devices with electrical safety implications — a compromised controller could manipulate charging parameters, disable safety interlocks, or pivot into facility building-management networks. That OT safety dimension floors the verdict at HIGH even with limited internet exposure.

Why this verdict

• OT safety floor enforced: CHARX SEC controllers manage electrical safety interlocks for EV charging. Root compromise can tamper with overcurrent protection and charging parameters, creating physical safety risk. This floors the verdict at HIGH per the OT/ICS/SCADA catalog.
• Role multiplier: (a) *Low-value role* — lab/demo units: chain succeeds, blast radius = single device (LOW). (b) *Typical role* — production charging station on site LAN: chain succeeds if attacker has local network access, blast radius = charging point + potential pivot to facility network (MEDIUM-HIGH). (c) *High-value role* — charging infrastructure connected to fleet management / grid operator backend: chain succeeds, blast radius = safety impact + potential grid load manipulation + lateral movement to OT network (HIGH). The high-value role is plausible for ≥1% of installs, enforcing the HIGH floor.
• Friction downward from CRITICAL: No internet exposure population found on Shodan/Censys. Controllers are embedded appliances inside physical enclosures, accessed via Ethernet or 4G APN — not routinely exposed to the internet. Attacker needs local network access or compromised backend/VPN in most deployments.
• No active exploitation: Zero KEV listing, no in-the-wild campaigns, EPSS at 0.42%. No public PoC weaponization. This removes the urgency multiplier that would push back toward CRITICAL.
• Repeat-offender codebase but injectable parameter is named: The CHARX SEC firmware has had prior command injection bugs (Pwn2Own Automotive 2024). The idledisconnect parameter is named in the advisory, which lowers the exploitation difficulty for a motivated attacker — but the niche target population limits mass exploitation.

Why not higher?

CRITICAL would require either active exploitation (KEV/campaigns), significant internet-facing exposure, or a canonical high-value role where ≥10% of the installed base occupies that role by definition. CHARX SEC controllers are niche OT devices with no confirmed internet exposure and no exploitation activity. The safety implications are real but localized to individual charging stations in most deployments, not fleet-scale or supply-chain-scale.

Why not lower?

MEDIUM or below would ignore the OT/ICS safety dimension. This is an unauthenticated root RCE on a device that controls electrical charging parameters — physical safety implications (fire, electrical hazard) are non-trivial. The attack chain has zero friction once the network is reached (no auth, no interaction, low complexity). Prior Pwn2Own research confirms the codebase is exploitable. The HIGH floor for OT/ICS safety-critical devices applies.

1. Segment charging controllers onto dedicated OT VLAN — Isolate CHARX SEC controllers from corporate networks and restrict management access to a dedicated OT management VLAN. This eliminates the most common pivot path. Deploy within 30 days per noisgate mitigation SLA for HIGH.
2. Restrict management interface access via firewall rules — Block all inbound traffic to the SCM component except from authorized management stations. If using 4G backhaul, ensure the APN is private and not routable from the internet. Apply ACLs at the network edge and on any VPN concentrators.
3. Monitor OCPP backend for anomalous sessions — Alert on unexpected charging parameter changes, firmware update attempts, or unusual session patterns from controller IPs. This provides detection-in-depth while waiting for the firmware update.
4. Apply firmware 1.9.1 — The definitive fix. Schedule firmware updates through Phoenix Contact support channels. For large fleets, coordinate with your charging station O&M provider. Target completion within 180 days per noisgate remediation SLA for HIGH.

Run this script on any Linux/macOS workstation that can reach the CHARX SEC controller's management IP. Invoke with: bash check_charx_cve2026-7849.sh <controller-ip>. No special privileges required — it queries the device firmware version via the controller's API.

#!/usr/bin/env bash
# check_charx_cve2026-7849.sh — Check Phoenix Contact CHARX SEC firmware version
# Usage: bash check_charx_cve2026-7849.sh <controller-ip>
# Requires: curl, network access to CHARX SEC management interface
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <controller-ip>"
  exit 2
fi

TARGET="$1"
TIMEOUT=10

# Attempt to retrieve firmware version from CHARX SEC API
# The device exposes version info on its web interface
FW_RAW=$(curl -sk --connect-timeout "$TIMEOUT" "https://${TARGET}/api/system/info" 2>/dev/null || \
         curl -sk --connect-timeout "$TIMEOUT" "http://${TARGET}/api/system/info" 2>/dev/null || \
         echo "")

if [ -z "$FW_RAW" ]; then
  echo "UNKNOWN — Could not connect to CHARX SEC at ${TARGET}. Verify IP and network path."
  exit 2
fi

# Extract firmware version (expected format: X.Y.Z)
FW_VERSION=$(echo "$FW_RAW" | grep -oP '"firmware[Vv]ersion"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+' || echo "")

if [ -z "$FW_VERSION" ]; then
  echo "UNKNOWN — Connected to ${TARGET} but could not parse firmware version from response."
  echo "Raw response (first 500 chars): ${FW_RAW:0:500}"
  exit 2
fi

echo "Detected firmware version: ${FW_VERSION}"

# Compare version against fixed version 1.9.1
IFS='.' read -r MAJOR MINOR PATCH <<< "$FW_VERSION"
FIXED_MAJOR=1
FIXED_MINOR=9
FIXED_PATCH=1

if [ "$MAJOR" -gt "$FIXED_MAJOR" ] 2>/dev/null; then
  echo "PATCHED — Firmware ${FW_VERSION} is above the fixed version 1.9.1."
  exit 0
elif [ "$MAJOR" -eq "$FIXED_MAJOR" ] && [ "$MINOR" -gt "$FIXED_MINOR" ] 2>/dev/null; then
  echo "PATCHED — Firmware ${FW_VERSION} is above the fixed version 1.9.1."
  exit 0
elif [ "$MAJOR" -eq "$FIXED_MAJOR" ] && [ "$MINOR" -eq "$FIXED_MINOR" ] && [ "$PATCH" -ge "$FIXED_PATCH" ] 2>/dev/null; then
  echo "PATCHED — Firmware ${FW_VERSION} meets or exceeds the fixed version 1.9.1."
  exit 0
else
  echo "VULNERABLE — Firmware ${FW_VERSION} is below the fixed version 1.9.1. CVE-2026-7849 applies."
  exit 1
fi

Sources

1. INCIBE advisory on CHARX SEC vulnerabilities (2026-07-30)
2. Canadian Centre for Cyber Security — Phoenix Contact Advisory AV26-546
3. RET2 Systems — Pwn2Own Automotive 2024 CHARX SEC bugs
4. VicOne — Pwn2Own Automotive CHARX SEC-3100 RCE vulnerabilities
5. runZero — Finding Phoenix Contact assets
6. Phoenix Contact PSIRT
7. Phoenix Contact CHARX SEC-3100 product page