Source: Unit 42 / Palo Alto Networks, “Three Steps to the Terminal: A Siemens ROX II Zero-Day Trilogy”.

Unit 42 and Siemens disclosed a three-part vulnerability chain affecting Siemens Ruggedcom ROX II operational technology switches. The important part is not just that one device family needs firmware attention. The bigger lesson is that OT switches are no longer passive plumbing. In many environments they are privileged, trusted control-plane assets sitting between HMIs, PLCs, engineering workstations, and remote access paths.

What was reported

The research describes three vulnerabilities that can be chained against affected ROX II devices:

  • CVE-2025-40948: arbitrary file disclosure through misuse of the xz utility by a privileged process, potentially exposing configuration data, credentials, hashes, or keys.
  • CVE-2025-40947: command injection in feature key validation, allowing attacker-controlled input to reach a root-privileged command path.
  • CVE-2025-40949: command injection in the web management task scheduler, enabling persistent root-level execution that can survive reboots.

Siemens recommends updating affected ROX II devices to firmware version V2.17.1. In OT networks where patch windows are constrained, compensating controls become the immediate priority.

Why this matters

An industrial switch compromise is different from a normal endpoint compromise. A switch can observe, shape, interrupt, or redirect traffic between operational assets. If an attacker gains root on a switch inside an OT segment, they may be able to support credential theft, persistence, denial-of-service activity, network reconnaissance, or tampering with traffic paths that defenders assume are trusted.

For government contractors, utilities, manufacturers, maritime operators, and small industrial businesses, the risk is practical: many OT networks have older management interfaces, long maintenance cycles, and limited monitoring at the device-management layer. That creates a gap between “we know the CVE exists” and “we can actually patch this without disrupting operations.”

Defensive takeaways

  • Identify exposure first. Build or update an inventory of Ruggedcom/ROX II assets, firmware versions, management interfaces, and who can reach them.
  • Prioritize firmware V2.17.1 testing. Treat the update like an operational change: lab test, schedule a maintenance window, document rollback steps, then deploy.
  • Restrict management access. ROX II web management and administrative services should be reachable only from dedicated jump hosts or management VLANs, not broad OT or IT networks.
  • Watch for behavior, not just IOCs. Monitor for unusual scheduled tasks, unexpected scripts, suspicious use of utilities like xz, and configuration changes on OT switches.
  • Use virtual patching where patching lags. Network-layer detection and prevention can reduce exposure while operations teams validate firmware updates.
  • Audit credentials and keys. Because the chain includes file disclosure, assume sensitive device files could be targeted and review secrets used by or stored on affected devices.

Bulwark Black assessment

This is a strong example of why OT security programs need asset-level monitoring and change control for infrastructure devices, not just PLCs and Windows engineering workstations. A ruggedized switch may look boring, but if it carries privileged management functions and sits in the middle of operational traffic, it deserves the same visibility and hardening attention as any high-value server.

The proper defensive move is layered: patch the firmware, reduce management-plane reachability, monitor administrative behavior, and keep compensating controls in place for sites that cannot move quickly. For smaller operators and contractors, the win is not a perfect OT SOC overnight. The win is knowing which devices matter, who can reach them, what normal admin behavior looks like, and how quickly you can detect a change that should not be there.