An unauthenticated remote attacker can upload a malicious IODD file that places and executes a shell script…

CVE-2026-27565 affects IO-Link master devices from three vendors sharing a common firmware platform: Phoenix Contact IOL MA8 EIP DI8 / IOL MA8 PN DI8, Pepperl+Fuchs ICE2-\*/ICE3-\* series, and Carlo Gavazzi YL212\*/YN115\*. All firmware versions below 1.7.4 are vulnerable. An unauthenticated remote attacker can upload a crafted IODD (IO-Link Device Description) file through the device's web management interface that places and executes a shell script with root privileges. The implant persists across reboots, giving the attacker a permanent foothold on the device. The flaw sits alongside 20+ sibling CVEs in the same advisory batch, including authentication bypass (CVE-2026-27546, also 9.8), path traversal leaking SSH private keys (CVE-2026-27557), and multiple authenticated command injection endpoints — making the entire web interface of these devices a target-rich environment.

The vendor CVSS of 9.8 CRITICAL is accurate and, if anything, understates the operational risk. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H correctly captures the unauthenticated, zero-interaction nature of the attack. What CVSS cannot capture is the OT blast radius: these are field-level industrial I/O controllers that bridge digital commands to physical sensors and actuators. Root access means an attacker can manipulate process data, disable safety interlocks, or pivot deeper into the OT network — consequences that go beyond confidentiality/integrity/availability into the realm of physical safety. The persistence across reboots further elevates the real-world severity beyond what the score alone conveys.

Why this verdict

• Unauthenticated RCE to root — the attack requires zero credentials, zero user interaction, and a single HTTP POST. This is the simplest possible exploit chain for maximum impact.
• Reboot persistence — the implant survives power cycles, meaning the attacker maintains access until the device is reflashed. This transforms a vulnerability into a permanent backdoor.
• Role multiplier: OT/ICS field device — IO-Link masters are industrial I/O controllers that bridge digital commands to physical sensors and actuators. 100% of installations serve this high-value role. Compromise enables process data manipulation, actuator hijacking, and lateral movement into the broader OT network. The blast radius is operational/safety-scale, not just IT-scale.
• Multi-vendor shared firmware — three major industrial automation vendors ship the same vulnerable firmware platform, broadening the affected population across the IO-Link ecosystem. This is effectively a supply-chain-adjacent issue.
• Companion vulns amplify impact — CVE-2026-27546 (auth bypass, 9.8) and CVE-2026-27557 (SSH key disclosure, 7.5) in the same advisory batch mean even if this specific CVE were somehow mitigated, adjacent attack paths exist on the same devices.

Why not higher?

The score is already at the CVSS ceiling of 9.8. The only thing preventing a theoretical 10.0 is the Unchanged scope — while OT blast radius extends beyond the device, the CVSS model's Scope metric doesn't fully capture cross-domain impact to physical safety systems. At 9.8 CRITICAL, this is already at the maximum actionable severity level.

Why not lower?

Network segmentation is the only friction point, and it is a deployment assumption, not an architectural guarantee. Purdue Model Level 1 segmentation is aspirational in many manufacturing environments — flat OT/IT networks remain widespread. Even in segmented environments, any attacker with OT network access (insider, compromised engineering workstation, VPN credential theft) reaches the device trivially. The 100% high-value-role installation base, zero-friction exploit chain, and reboot persistence collectively floor this at CRITICAL regardless of network topology assumptions.

1. Isolate IO-Link masters behind OT firewall with explicit allow-list rules — Block all HTTP/HTTPS access to the device management interface from any network segment except dedicated engineering workstations. This is the single most effective compensating control and should be deployed within the noisgate mitigation SLA of ≤3 days. Use your OT firewall (Palo Alto, Fortinet, Cisco) to create zone-based rules that restrict TCP/80 and TCP/443 to the device's IP from only pre-approved source IPs.
2. Disable or restrict IODD upload functionality at the network layer — If your OT firewall supports deep packet inspection, create a rule blocking HTTP POST requests to /index.php/attached_devices_tab/do_upload and similar upload endpoints on IO-Link master IPs. Deploy within ≤3 days per noisgate mitigation SLA.
3. Deploy OT network monitoring on IO-Link master segments — If you run Nozomi Guardian, Claroty xDome, or Dragos Platform, ensure sensors cover the VLAN(s) where IO-Link masters reside. Create alerts for any HTTP session to these devices from non-engineering-workstation IPs. This provides detection-in-depth while you patch.
4. Update firmware to 1.7.8 on all affected devices — This is the definitive remediation. Schedule firmware updates within the noisgate remediation SLA of ≤90 days, prioritizing devices on less-segmented network segments. Coordinate with plant operations for maintenance windows — OT firmware updates typically require physical presence or engineering workstation access.
5. Rotate SSH keys and credentials on all affected devices — CVE-2026-27557 in the same advisory batch exposes SSH private keys to unauthenticated attackers. Even after patching CVE-2026-27565, assume key material is compromised. Regenerate SSH host keys and change all user passwords post-firmware-update.

Run this script from an engineering workstation or auditor laptop with network access to the IO-Link master's web interface. Invoke with: bash check_cve_2026_27565.sh <DEVICE_IP>. No authentication or special privileges required — the check uses unauthenticated HTTP requests to fingerprint the firmware version.

#!/usr/bin/env bash
# check_cve_2026_27565.sh — Check IO-Link master firmware for CVE-2026-27565
# Usage: bash check_cve_2026_27565.sh <DEVICE_IP>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

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

TARGET="$1"
TIMEOUT=10

# Try HTTPS first, fall back to HTTP
for PROTO in https http; do
  RESPONSE=$(curl -sk --connect-timeout "$TIMEOUT" --max-time "$TIMEOUT" "${PROTO}://${TARGET}/" 2>/dev/null) && break
  RESPONSE=""
done

if [ -z "$RESPONSE" ]; then
  echo "UNKNOWN — could not connect to ${TARGET} on HTTP or HTTPS"
  exit 2
fi

# Extract firmware version from web interface
# Common patterns: "Firmware Version: 1.x.y" or "fw_version":"1.x.y"
FW_VERSION=$(echo "$RESPONSE" | grep -oP '(?i)(firmware[\s_-]*version|fw_version)[^0-9]*(\d+\.\d+\.\d+)' | grep -oP '\d+\.\d+\.\d+' | head -1)

if [ -z "$FW_VERSION" ]; then
  # Try the status/info API endpoint
  for PROTO in https http; do
    INFO=$(curl -sk --connect-timeout "$TIMEOUT" --max-time "$TIMEOUT" "${PROTO}://${TARGET}/index.php/ajax/get_device_info" 2>/dev/null) && break
    INFO=""
  done
  FW_VERSION=$(echo "$INFO" | grep -oP '\d+\.\d+\.\d+' | head -1)
fi

if [ -z "$FW_VERSION" ]; then
  echo "UNKNOWN — connected to ${TARGET} but could not extract firmware version"
  echo "Manual check: browse to the device web UI and verify firmware >= 1.7.8"
  exit 2
fi

echo "Detected firmware version: ${FW_VERSION}"

# Compare versions: vulnerable if < 1.7.4 (advisory says <1.7.4 affected, fixed in 1.7.8)
# We flag anything below 1.7.8 as vulnerable since 1.7.8 is the patched release
IFS='.' read -ra VER <<< "$FW_VERSION"
MAJOR=${VER[0]:-0}
MINOR=${VER[1]:-0}
PATCH=${VER[2]:-0}

if [ "$MAJOR" -lt 1 ] || \
   ([ "$MAJOR" -eq 1 ] && [ "$MINOR" -lt 7 ]) || \
   ([ "$MAJOR" -eq 1 ] && [ "$MINOR" -eq 7 ] && [ "$PATCH" -lt 8 ]); then
  echo "VULNERABLE — firmware ${FW_VERSION} is below patched version 1.7.8 (CVE-2026-27565)"
  exit 0
else
  echo "PATCHED — firmware ${FW_VERSION} is at or above patched version 1.7.8"
  exit 1
fi

Sources

1. CERT@VDE Advisory VDE-2026-027 — Phoenix Contact IOL MA8
2. CERT@VDE Advisory VDE-2026-014 — Pepperl+Fuchs ICE2/ICE3
3. CERT@VDE Advisory VDE-2026-028 — Carlo Gavazzi YL212/YN115
4. CERT@VDE Advisories Index
5. Phoenix Contact IOL MA8 PN DI8 Product Page
6. Nozomi Networks Vulnerability Advisories
7. SEC Consult Prior IO-Link Master Advisory (2020 — same device family)
8. CVE Project Release — 2026-09-16