A Siemens ROX II Zero-Day Trilogy

We conducted this research in close partnership with Siemens, reflecting our shared commitment to advancing the security and resilience of critical infrastructure.

The Palo Alto Networks OT Threat Research Lab and Siemens partnered to advance the security and resilience of critical infrastructure through collaborative vulnerability research on the Ruggedcom ROX II platform. We combined the OT Threat Research Lab’s expertise in industrial cybersecurity research with Siemens’ deep product knowledge and the coordination capabilities of Siemens ProductCERT. These teams worked together to identify, validate, remediate and responsibly disclose security vulnerabilities.

This collaboration reflects the growing importance of industry partnerships in securing OT environments. As critical infrastructure enters the AI era, organizations must work together more closely than ever to address emerging threats, accelerate vulnerability remediation and strengthen the security of the technologies that support essential services worldwide. This partnership demonstrates how coordinated research and responsible disclosure can help build a more resilient and secure future for critical infrastructure.

The modern OT environment is a complex network of devices working in concert. At the heart of this connectivity are OT switches, which act as the nervous systems of industrial networks, directing communication between critical assets like human-machine interfaces (HMIs) and programmable logic controllers (PLCs).

Protecting the integrity and availability of these switches is paramount for any industrial operation, be it a factory floor or a power plant. For instance, a properly configured OT switch provides crucial network segmentation, which enhances security by isolating different parts of the network while still allowing necessary communication.

However, OT switches designed to secure the network can themselves become attack surfaces. A common misconception is that because these devices are often air-gapped or sit on isolated networks, they’re inherently safe. In reality, they are just as susceptible to software vulnerabilities as any other IT equipment, allowing an unprivileged attacker to exploit software flaws, escalate privileges and disrupt OT communication.

This threat research article demonstrates how seemingly benign flaws can be exploited to initiate a chain of events. In this case, this could lead to full control of the critical OT switch operating system ROX II.

During the initial analysis of the switch’s publicly available firmware, we worked with Siemens researchers and located a key configuration file associated with a privileged daemon. This file is used by a management and configuration daemon running with root privileges on the switch’s operating system. As a root-privileged process, it can perform any action on the system, including reading and writing any file.

This insecure configuration creates a significant arbitrary file disclosure vulnerability. An attacker can leverage this to:

• Read sensitive configuration and system files containing credential information
• Access private keys or other cryptographic materials
• Gather information about the system and network, paving the way for further attacks

In the case of the ROX II switch, this oversight would have allowed an attacker to leak the contents of any file on the file system. This highlights the importance of carefully vetting all commands executed by privileged processes and ensuring that user input is never used to construct commands insecurely.

To understand CVE-2025-40947, we must first understand how the Siemens feature key mechanism works. A feature key is a cryptographically signed license that enables specific functionalities on the switch. When a customer purchases a license, Siemens provides a signature (i.e., the feature key) that the customer installs on the device. The switch then uses a pre-installed public key to verify the feature key’s authenticity and enable the corresponding features. This process is intended to be secure, but our analysis revealed a critical flaw in its implementation.

By reverse engineering the feature key handling library (responsible for installation), we identified the CVE-2025-40947 vulnerability in its signature verification function. This function is responsible for validating the signature provided in the feature key. The function involves three important steps:

1. Read and parse: The function reads from the feature key file and parses a signature line containing up to a fixed number of characters
2. Command preparation: It then prepares a Linux command to verify the signature using the gpgv utility, inserting the parsed signature string directly into the command
3. Command execution: Finally, it executes the constructed command using system() with root privileges

The code excerpt in Figure 1 shows how the signature is copied into the command string before being executed. This is the root cause of the command injection vulnerability, as there is no sanitization or validation of the input signature before it is inserted into the command string.

To exploit this vulnerability, an attacker needs to craft a payload that fits within the signature field size limit. The exploitation process involves two main steps:

1. File upload: The attacker first uses the web UI’s normal file upload functionality for a feature key to upload a malicious script (e.g., a Python reverse shell) to a writable directory on the switch.
2. Command injection: Next, the attacker crafts a new feature key file where the signature field contains a command injection payload. This payload is designed to execute the malicious script that was previously uploaded. For example, a payload like $(python /tmp/rev_shell.py) could be used, where /tmp/rev_shell.py is the uploaded script.

When the attacker uploads this specially crafted feature key, the vulnerable verification function will execute the injected command with root privileges, giving the attacker a reverse shell and full control over the device. This attack vector highlights the importance of robust input validation and secure coding practices, especially when handling external data and executing system commands.

Following the initial privilege escalation, we discovered a third critical vulnerability, CVE-2025-40949, in the Siemens ROX II switch’s system scheduling functionality. This flaw allows an authenticated attacker to establish persistent execution of arbitrary commands with root privileges.

The vulnerability resides in the switch’s system task scheduler, which is used to automate periodic command execution. An authenticated attacker can manipulate input fields within the web management interface used to configure scheduled tasks.

Due to improper sanitization and validation of user-supplied data, the attacker can inject control characters and commands into the underlying system configuration file responsible for task execution. This technique results in a command injection attack executed with root privileges. The impact is persistent code execution as the root user, enabling long-term compromise that survives system reboots and maintains control over the device.

Exploiting this vulnerability involves several steps that an authenticated attacker can perform via the web management interface. This high-level summary demonstrates how persistent root access is achieved.

• Step 1 – Prepare the malicious code: The attacker prepares malicious code, such as a script designed for communication or system manipulation. This payload is stored in a location accessible by the switch’s operating system.
• Step 2 – Inject the command: The attacker uses the task scheduler interface to create a new scheduled task. By crafting a special input string for some of the task configuration fields, the attacker is able to inject an execution command. This command is structured to overwrite or bypass the intended task parameters, causing the system to execute the attacker’s payload instead of a legitimate function.
• Step 3 – Execute and achieve persistence: Once the configuration is saved, the scheduled task mechanism processes the injected command. This results in the execution of the attacker’s prepared code with root privileges, achieving persistent control over the device. This control remains active through system operations, allowing for ongoing malicious activity.

The discovery and mitigation of these three chained zero-day vulnerabilities in Siemens ROX II switches highlight the necessity of collaborative vulnerability research between vendors and security researchers. By working together to identify and remediate flaws that could allow full system compromise, the industry can better protect the critical infrastructure that underpins essential services.

To protect the intricate and interconnected OT environment, organizations must execute a defense-in-depth strategy. This methodology must combine timely firmware updates with compensating controls, such as virtual patching.

While applying vendor-provided security updates remains the recommended long-term remediation, organizations may require additional time to test and deploy patches within OT environments.

System behavior indicators:

• Unusual task scheduler entries:
  • Description: Unexpected scripts or commands injected into the switch’s system configuration files or task scheduler configuration. These are typically characterized by the execution of arbitrary commands (e.g., python, bash or direct system calls) instead of legitimate task functions.
• Abnormal use of the xz utility:
  • Description: Execution of xz with parameters -f, -c and -d by the privileged configuration daemon. This indicates an attempt to read files on the file system that are not normally accessible to the user.

Adam Robbie, Head of OT Threat Research, Emmanuel Zhou, Sr. Staff Researcher and Rick Wyble, OT Security Researcher, are researchers affiliated with the Palo Alto Networks Advanced Research Center for OT. Miguel Pereira is from Siemens ProductCERT.