Nozomi identifies 19 vulnerabilities in Pepperl+Fuchs IO

Researchers from Nozomi Networks Labs identified 19 vulnerabilities in the Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45 running EtherNet/IP firmware version 1.7.3. They found that the flaws included an authentication bypass that could allow a network-reachable attacker to obtain an administrator session without valid credentials, as well as multiple operating system command injection vulnerabilities capable of executing commands with root privileges. The affected device serves as a connection point between field-level sensors and actuators and higher-level industrial control systems, increasing the potential significance of a compromise.

Nozomi also found other vulnerabilities in the device’s web interface and related functions that could enable unauthorized access or disruption. Pepperl+Fuchs fixed the reported flaws through coordinated disclosure, and CERT@VDE published an advisory covering the affected products and vulnerabilities.

The most notable is a logic flaw in the authentication mechanism, tracked as CVE-2026-27546, which exploits the device’s initial password setup function. Under specific conditions, the WebUI wrongly treated an unauthenticated login attempt as part of first-time configuration, letting an attacker skip the credential check and obtain an administrative session. The flaw is especially significant because it affects the main interface used to configure the device, monitor IO-Link ports and perform firmware updates. With an administrative session, an attacker gains access to several privileged operations never meant to be reachable without authentication.

The researchers said successful exploitation could enable an attacker to modify IO-Link port configurations, manipulate sensor readings, inject commands to actuators, disable the IO-Link master, or use the compromised device as a pivot toward other operational technology systems.

“The analysis targeted the Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45, a DIN-rail-mounted module (IP20) designed for control cabinet installation in factory automation environments,” Nozomi researchers wrote in a blog post. “The device communicates upstream with PLCs via EtherNet/IP, with SCADA and HMI systems via Modbus TCP, with engineering tools via OPC UA, and with cloud and IIoT platforms via MQTT.”

They added that the tested firmware version was EtherNet/IP 1.7.3. “Our research focused on the HTTPS-based management interface, which control engineers and maintenance personnel use to configure the device, monitor IO-Link ports and manage IODD files.”

An IODD, or IO Device Description, is a standardized file that tells an IO-Link master how to identify and interact with a connected sensor or actuator. It describes key information such as device parameters, process data, diagnostics, and communication properties, allowing the WebUI to present device configuration in a human-readable way.

“The WebUI implements role-based access control with three predefined accounts (Admin, Operator, and User), each with progressively restricted permissions,” according to Nozomi’s post. “These accounts are intended to be protected by administrator-defined credentials to enforce access control according to the operational role.”

The research covered the PHP-based WebUI application served at /index.php/ paths and the CGI-based REST API endpoints at /api/ paths. Both components run with root privileges on the device operating system, which means any code execution vulnerability in either interface immediately grants the highest system privilege level.

The Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45 operates as the bridge between field-level sensors and the plant’s industrial Ethernet backbone. In a typical deployment, the device sits on a DIN rail inside a control cabinet, connected to pressure sensors, flow meters, or pneumatic actuators. Control engineers use the HTTPS web interface to configure IO-Link ports, upload IODD description files for newly installed sensors, monitor field device status, and manage user accounts. A PLC on the upstream network depends on this module for real-time process data and actuator commands across all eight IO-Link ports.

Nozomi identified that the most direct attack path uses an authentication bypass (CVE-2026-27546), where the login mechanism doesn’t validate usernames against the stored credential database. By supplying a specific crafted username, an attacker receives an Admin-level session whether or not passwords are configured. The attacker can then exploit any of several OS command injection flaws in the REST API endpoints.

Since the web application daemon runs as root, this gives full operating-system control. From there, the attacker can modify IO-Link port configurations, intercept or alter sensor readings, inject actuator commands, install persistent backdoors, or pivot to other OT network devices. The whole chain, from unauthenticated network access to a root shell, takes only two HTTPS requests and under a second.

In the second path, it observed a separate unauthenticated path that targets the device’s SSH private keys. The IODD file viewer endpoint is vulnerable to path traversal (CVE-2026-27557), letting any unauthenticated attacker read files from sensitive directories. Because the Dropbear SSH server stores its private keys in a reachable location, an attacker can extract them with a single HTTPS request. With the stolen keys, the attacker can impersonate the device’s SSH server and intercept an engineer’s routine maintenance session to harvest their credentials. This path is particularly stealthy, requires no authentication, and leaves minimal forensic evidence.

Vulnerabilities in the Pepperl+Fuchs IO-Link Master can have serious consequences for the device and the industrial environment it supports. Because the master sits between field devices and the PLC, its compromise directly affects process visibility and control. The impacts align with MITRE ATT&CK for ICS techniques, starting with initial access (T0866: Exploitation of Remote Services): the authentication bypass (CVE-2026-27546) and the unauthenticated path traversal (CVE-2026-27557) let any host that can reach the device over HTTPS obtain an Admin session or extract the SSH server’s private keys, with no credentials required.

Once an attacker has root-level access through the OS command injection flaws, they can manipulate both control and process data. Under T0831 (Manipulation of Control), they can modify IO-Link port parameters and interfere with actuator commands from the PLC to field devices, such as valve positioning, motor control or pneumatic actuation, causing incorrect physical behavior without triggering alerts in the control system.

Under T0832 (Manipulation of View), they can alter sensor data before it reaches the PLC, OPC UA clients or MQTT consumers, so operators and automated systems keep seeing normal-looking readings while the real process state diverges. Where those readings feed safety interlocks or quality control, falsified data could lead to defective products, equipment damage or hazardous conditions.

Root access also enables disruption and lateral movement. Under T0826 (Loss of Availability), an attacker can disable the IO-Link master or its communication services, cutting the PLC off from all eight attached field devices; depending on failover behavior, the controller could enter a fault state, operate on stale data, or halt the process.

Under T0886 (Remote Services), the stolen SSH keys (CVE-2026-27557) let the attacker impersonate the device’s SSH server and harvest credentials from engineers performing routine maintenance. If those credentials are reused within the network segment, the attacker can move laterally to other IO-Link masters, PLCs or HMI systems, and the fully compromised device can serve as a pivot point for reconnaissance and further attacks within the OT network.

“After analyzing the WebUI and the REST API implementation, we found that several management functions passed user-controlled input to operating-system commands without sufficient validation or isolation. This pattern appeared in both the PHP-based WebUI and in native CGI components used by the REST API,” the post added. “One affected area was the IODD file management functionality. IODD files are used by the IO-Link master to describe connected sensors and actuators, including their parameters, process data, and diagnostics. Because the WebUI allows users to upload and manage these files, this functionality handles attacker-controlled input as part of normal device administration.”

In vulnerable code paths, this input was later used to build shell commands. If an attacker had access to the affected functionality, they could abuse this behavior to execute arbitrary commands on the device. Since the affected components run with high privileges, successful exploitation would result in full control of the underlying operating system.

Nozomi observed the same underlying weakness in multiple CGI-based API handlers. Some of these handlers also used unsafe memory operations while preparing command strings, introducing an additional memory-corruption risk. These issues are tracked across several CVEs, including CVE-2026-27549 and CVE-2026-27559 through CVE-2026-27564.

The key point is not that a single endpoint was implemented incorrectly, but that the same unsafe design pattern appeared across different parts of the management stack: user-controlled data crossed a trust boundary and reached privileged system commands without adequate validation.

“Not all critical attack paths require authentication. For instance, we identified an unauthenticated path traversal vulnerability in the IODD file viewing functionality, tracked as CVE-2026-27557,” Nozomi disclosed. “The affected feature is intended to display IODD files stored on the device. However, insufficient path validation allowed a remote attacker to access files outside the expected IODD directory, including sensitive material stored on the device filesystem.”

In this case, the exposed data included SSH host keys used by the device to identify itself during remote management sessions. While stealing these keys does not directly grant shell access, it can enable a stealthier follow-on attack. An attacker with a privileged network position could redirect an engineer’s SSH connection to an attacker-controlled system while presenting the same host identity as the real device.

The post noted that this position could be obtained, for example, through ARP spoofing, DNS spoofing, or control of a network component capable of redirecting traffic. From the engineer’s point of view, the connection may appear legitimate because the expected device identity is preserved.

“If password-based authentication is used, the attacker could capture the credentials entered during the maintenance session,” according to the Nozomi researchers. “The same scenario could also expose machine-to-machine credentials if automated tools or other systems connect to the device over SSH. If these credentials are reused elsewhere, the impact could extend beyond the original IO-Link master and support lateral movement inside the OT environment.”

This makes the vulnerability particularly concerning: it requires no prior authentication, can expose sensitive device material, and may enable credential theft with limited evidence left on the target device. For operators, it reinforces the importance of isolating management interfaces, monitoring access to industrial devices, and avoiding credential reuse across the OT network.

In conclusion, the Nozomi researchers found that the Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45, running firmware EtherNet/IP 1.7.3, contains critical security weaknesses that let an unauthenticated network attacker gain full root-level control of the device. The 19 vulnerabilities span authentication bypass, OS command injection, path traversal, local file inclusion, incorrect authorization and information disclosure, collectively undermining every trust boundary in the device’s access control model.

Until a patched firmware version is available, asset owners should reduce exposure by isolating the device’s WebUI and SSH ports on a dedicated management VLAN, with strict access control lists that limit connectivity to authorized engineering workstations only. They should also disable any unused services, such as SSH, OPC UA or MQTT, to shrink the attack surface, and set strong, unique passwords for all three roles (Admin, Operator and User) to limit credential-based access, although this does not mitigate the authentication bypass.

Asset owners should also monitor for anomalous traffic, watching for unusual HTTP requests to the device, especially login attempts with non-standard usernames, path traversal patterns and unexpected outbound connections from the device’s IP address. Finally, they should verify the device’s SSH host key on first connection and watch for unexpected key changes, which may indicate server impersonation.