Pepperl+Fuchs is a leading manufacturer of industrial sensors and interface modules. The IO-Link Master ICE2-8IOL-K45P-RJ45 is an industrial communication gateway that connects up to eight IO-Link sensors and actuators to higher-level control systems such as PLCs, SCADA platforms, and IIoT services. IO-Link is a standardized point-to-point serial protocol (IEC 61131-9) that enables smart field devices to exchange process data, diagnostic information, and configuration parameters with the control network. In factory automation, packaging, and material handling environments, IO-Link masters like this one serve as the bridge between physical process instrumentation and the digital control layer.
Nozomi Networks Labs analyzed the ICE2-8IOL-K45P-RJ45 running firmware version EtherNet/IP 1.7.3 and identified 19 vulnerabilities across its web-based management interface. The most critical finding is an authentication bypass that allows any network-reachable attacker to obtain an Admin session without valid credentials. Combined with pervasive OS command injection flaws (all executing as root) this bypass gives an unauthenticated attacker full control of the device operating system.
Because the IO-Link master feeds real-time sensor data to PLCs and relays actuator commands to the field, a compromised device can disrupt process visibility and control across all eight connected ports. Asset owners who deploy this product should review the findings and apply the recommended mitigations.
We thank Pepperl+Fuchs and CERT@VDE for the close collaboration throughout the coordinated disclosure process. Pepperl+Fuchs addressed all reported vulnerabilities in a timely manner, while CERT@VDE coordinated the disclosure activities and released the VDE-2026-014 advisory to inform the affected users.
Pepperl+Fuchs has also informed us that they have held a certified Secure Development Lifecycle in accordance with IEC 62443-4-1 since 2023, embedding cybersecurity into every phase of product development to proactively address vulnerabilities in new products.
Research Scope – The Pepperl+Fuchs IO-Link Master
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. 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.
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. These accounts are intended to be protected by administrator-defined credentials to enforce access control according to the operational role.
The research covered both 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.
Attack Scenarios - How Attackers Can Compromise the IO-Link Master
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.
The device has a three-tier role model: Admin, Operator, and User. This mechanism is meant to ensure that only authorized personnel can change configuration or update firmware, while others are limited to monitoring. In normal operation, an engineer logs in through the WebUI with credentials matching their assigned role, performs a configuration task, and logs out.
The following diagram summarizes how an attacker who can reach the device's management interface over the network can bypass every layer of this trust model and gain full control of the underlying operating system.
The vulnerabilities we identified enable two distinct attack paths from the network to full device compromise.
Path 1: From the Network to Root, No Credentials Required
The most direct attack path exploits the authentication bypass (CVE-2026-27546). The login mechanism fails to validate usernames against the stored credential database: when an attacker supplies a specific crafted username, the server returns an Admin-level session regardless of whether passwords have been configured on the device.
Once authenticated as Admin, the attacker leverages any of the multiple OS command injection vulnerabilities present in the REST API endpoints (such as CVE-2026-27560, CVE-2026-27561 or CVE-2026-27562). Because the web application daemon runs as root, successful command injection immediately grants the attacker full operating-system control.
At this point, the attacker can modify IO-Link port configurations, intercept or alter sensor readings, inject actuator commands, install persistent backdoors, or pivot to other devices on the OT network.
This entire chain-from unauthenticated network access to a root shell-requires only two HTTPS requests and completes in under a second.
Path 2: Stealing SSH keys without Authentication
A separate unauthenticated attack path targets the device's SSH private keys. The IODD file viewer endpoint is vulnerable to path traversal (CVE-2026-27557), which allows any unauthenticated attacker to read files from sensitive directories on the device filesystem. Because the Dropbear SSH server stores its private keys under a reachable path, an attacker can extract them with a single HTTPS request.
With the stolen keys, the attacker can impersonate the device's SSH server. When an engineer connects for routine maintenance, the attacker intercepts the session and harvests the engineer's credentials. This path is particularly stealthy: it leaves minimal forensic evidence and requires no authentication at all.
Vulnerability Listing
Nozomi Networks Labs identified 19 vulnerabilities in the Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45 running firmware version EtherNet/IP 1.7.3.
Potential Impacts of the Vulnerabilities
The vulnerabilities identified in the Pepperl+Fuchs IO-Link Master can translate into serious consequences for both the device and the broader industrial environment it supports. Because the IO-Link master sits between field devices and the PLC, its compromise directly affects process visibility and control.
The following impacts align with techniques in the MITRE ATT&CK for ICS framework:
T0866: Exploitation of Remote Services
The authentication bypass (CVE-2026-27546) and the unauthenticated path traversal (CVE-2026-27557) allow an attacker to gain initial access to the device through its web-based management interface. No credentials are required. Any host that can reach the device over HTTPS can exploit these issues to obtain an Admin session or extract the SSH server's private keys.
T0831: Manipulation of Control
With root-level access obtained through any OS command injection vulnerabilities, an attacker can modify IO-Link port parameters and interfere with actuator commands flowing from the PLC to field devices. Depending on the connected process (e.g., valve positioning, motor control or pneumatic actuation) this manipulation could cause incorrect physical behavior without triggering alerts in the control system.
A compromised IO-Link master can alter sensor data before it reaches the PLC, OPC UA clients, or MQTT consumers. Operators and automated systems would continue to receive readings that appear normal while the actual process state diverges. In environments where these readings feed safety interlocks or quality control decisions, falsified data could lead to defective products, equipment damage, or hazardous conditions.
An attacker with root access can disable the IO-Link master or disrupt its communication services, severing the PLC's connection to all eight attached field devices. Depending on the PLC's failover behavior, this could cause the controller to enter a fault state, operate on stale data, or halt the process entirely.
The stolen SSH private keys (CVE-2026-27557) enable the attacker to impersonate the device's SSH server and harvest credentials from engineers who connect for routine maintenance. If those credentials are reused across other devices in the same network segment, the attacker can move laterally to additional IO-Link masters, PLCs, or HMI systems. Full OS compromise also positions the device as a pivot point for network reconnaissance and further attacks within the OT network.
Vulnerability Spotlight
This section focuses on the main security weaknesses we identified in the Pepperl+Fuchs IO-Link Master's web interface. Instead of covering every implementation detail, we highlight the recurring trust-boundary failures that made the device vulnerable: broken authentication logic, unsafe command execution, and unauthenticated access to sensitive files.
Together, these issues could allow a remote attacker with network access to the device to gain administrative control, execute commands with elevated privileges, or abuse sensitive device material to support stealthier attacks.
Authentication Bypass in the WebUI
The IO-Link Master's WebUI supports three predefined roles: Admin, Operator, and User. During the initial setup flow, the interface allows an administrator to configure credentials for these roles before the device is put into regular operation.
During our analysis, we identified a logic flaw in the authentication mechanism that exploit this initial password setup functionality: under specific conditions, the WebUI incorrectly treated an unauthenticated login attempt as part of the first-time configuration process. As a result, an attacker could bypass the expected credential check and obtain an administrative session.
This vulnerability, tracked as CVE-2026-27546, is particularly relevant because it affects the main management interface used to configure the device, monitor IO-Link ports and perform firmware updates. Once an attacker obtains an administrative session, the WebUI exposes several privileged operations that were not designed to be reachable by an unauthenticated user.
OS Command Injection Across WebUI Components
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.
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.
We 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.
Unauthenticated SSH Key Theft via Path Traversal
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.
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.
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. 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.
Conclusions and Remediations
This research demonstrates that the Pepperl+Fuchs IO-Link Master ICE2-8IOL-K45P-RJ45 running firmware EtherNet/IP 1.7.3 contains critical security weaknesses that allow an unauthenticated network attacker to gain full root-level control of the device. The 19 identified 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 apply the following mitigations to reduce exposure:
- Isolate management interfaces: Place 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.
- Disable unused services: If SSH, OPC UA, or MQTT are not operationally required, disable them to reduce the attack surface.
- Set strong, unique passwords: Configure passwords for all three roles (Admin, Operator, User) to limit credential-based access, even though this does not mitigate the authentication bypass.
- Monitor for anomalous traffic: Watch 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.
- Validate SSH host keys: Verify the device's SSH host key on first connection and monitor for unexpected key changes that may indicate server impersonation.
Consistent with Nozomi Networks Labs' mission, our goal is to provide operators and vendors with practical steps that improve the reliability and security of connected systems. We will continue to collaborate responsibly with the affected vendor and share guidance that helps make industrial and connected environments safer and more resilient.
To help organizations promptly identify whether the vulnerable device is present in their environment-and to detect and alert on exploitation attempts before they lead to operational disruption, compromise, or further attack progression-asset owners can rely on the advanced capabilities of Nozomi Networks OT/IoT Security Platform. The platform provides deep visibility into network traffic and device behavior, enabling effective vulnerability and threat detection across OT and IoT networks.
This proactive monitoring empowers security teams to respond to vulnerabilities and attacks swiftly and effectively, minimizing the impact of attacks targeting critical networks. To learn more about Nozomi Networks OT/IoT Security Platform and see it in action, request a demo today.
