Root-level command execution via malicious IODD upload in Pepperl+Fuchs, Phoenix Contact, and Carlo Gavazzi Automation devices

An unauthenticated remote attacker can upload a malicious IODD file that places and executes a shell script with root privileges. The shell script remains active even after a reboot.

The normalized record marks the following products as affected with an entry for 1.0.0 and an upper bound of <1.7.4 under semver:

• Pepperl+Fuchs: ICE2-8IOL1-G65L-V1D, ICE2-8IOL-G65L-V1D, ICE2-8IOL-K45P-RJ45, ICE2-8IOL-K45S-RJ45, ICE3-8IOL1-G65L-V1D, ICE3-8IOL-G65L-V1D, ICE3-8IOL-G65L-V1D-Y, ICE3-8IOL-K45P-RJ45, ICE3-8IOL-K45S-RJ45.
• Phoenix Contact: IOL MA8 PN DI8 and IOL MA8 EIP DI8 with firmware <1.7.4.
• Carlo Gavazzi Automation: YL212CEI8M1IO, YN115CEI8RPIO, YL212CPN8M1IO, and YN115CPN8RPIO with firmware <1.7.4.

The CERT@VDE advisories confirm the same below-1.7.4 firmware scope for all three vendor groups. The status of versions from 1.7.4 through before 1.7.8 is not established as unaffected or fixed by the available evidence.

The vulnerable processing path accepts an IODD file supplied by the attacker. A malicious IODD file can cause the device to place and execute a shell script with root privileges, consistent with CWE-78, OS Command Injection. Exploitation is remotely reachable over the network and does not require authentication or user interaction. The shell script remains active after a reboot, indicating that the attack can establish persistence on the device. Public evidence does not identify the exact parser, shell invocation, storage location, persistence mechanism, or specific endpoint involved.

The vulnerability is reachable over the network. The attacker does not need authentication or user interaction, and the supplied record describes low attack complexity. The record marks public_exploit as false and known_exploited as null; the consulted GCVE metadata displays exploitation as none. These statuses do not prove that unreported or unobserved exploitation is absent.

The direct technical outcome is arbitrary code execution with root privileges on an affected device. This can lead to unauthorized changes to device state and integrity, disclosure of sensitive information, and possible loss of device availability. Because the shell script remains active after reboot, malicious behavior may persist across restarts. The demonstrated scope is the vulnerable device itself; the available evidence does not confirm propagation to other systems or a specific compromise.

Successful exploitation can compromise device integrity because arbitrary code runs with root privileges. An attacker may maintain malicious code across reboots and potentially alter the device's operation or configuration. High-privilege execution may also expose sensitive information on the device and cause disruption to device control or monitoring functions. The available evidence does not identify a breach, victim, or confirmed impact on other systems.

1. Update firmware: Install firmware 1.7.8 on affected devices. This is the remediation version named in the CERT@VDE advisories for Pepperl+Fuchs, Phoenix Contact, and Carlo Gavazzi Automation.
2. Reduce exposure until updated: Do not leave affected devices directly reachable from the Internet, isolate them from the corporate network, and use a VPN or equivalent secure method when remote access is required.
3. Verify each model and firmware state: Confirm the actual device model and firmware before and after the update. Do not treat 1.7.4 as a confirmed fix merely because the affected range is recorded as <1.7.4; the available evidence specifically identifies 1.7.8 as the remediation target.
4. Review the device after remediation: Check uploaded IODD files, unapproved shell scripts, and unapproved processes, especially components that remain after reboot. If compromise is suspected, isolate the device and follow the organization's incident-response procedure.

1. Inventory Pepperl+Fuchs ICE2 and ICE3 devices, Phoenix Contact IOL MA8 devices, and Carlo Gavazzi Automation YL212 and YN115 models, then compare their firmware with the affected scope.
2. Check whether the devices are directly reachable from the Internet. CERT@VDE recommends minimizing network exposure, isolating affected products from the corporate network, and using a secure method such as a VPN for remote access.
3. If device audit logging is available, review unexpected IODD uploads and shell-script creation or execution around upload events. This is a precautionary review, not a vendor-confirmed IOC.
4. After a reboot, check for unapproved shell scripts or processes that continue to run. The absence of suspicious logs or processes does not prove that a device is safe.
5. The available evidence does not provide a vendor-specific log event, IOC, or detection signature.