Why this is current

CVE-2026-41551 is old in disclosure terms but current in operator terms. Siemens' May advisory says ROS# versions before 2.2.2 expose the file_server service to path traversal that could let a remote attacker read or write arbitrary files reachable with the service account's rights. Deception Check reports that an independent public proof-of-concept appeared on Aug. 25 and says its review was static, without executing the code. That changes testing priority; it does not establish exploitation.[1,5]

The affected boundary

ROS# is the C# bridge used to connect .NET or Unity applications to ROS. Siemens says the stack was intended for trusted local networks and that its WebSocket connection is not encrypted. The affected boundary is the ROS host running file_server or file_server2, not every workstation that merely has a ROS# client. CISA's May industrial-control bulletin lists the Siemens ROS# advisory, but the listing is not evidence of a robot compromise.[1,3,5]

The fix predated the alert

Siemens' ROS# 2.2.2 release was published on Apr. 22. Its changelog records path validation that blocks dot-directory traversal, enforces package://, uses canonical-path checks to keep a target inside its share directory, and makes allow_save and allow_overwrite default to false. NVD reproduces the vendor's 9.1 CVSS v3.1 and 9.3 CVSS v4.0 scores while noting that its own analysis is pending. The status is therefore patch available, not patch adopted.[1,2,4]

Risk without takeover claims

The cyber-physical risk depends on where the service is reachable, what the service account can read or write, and whether ROS or DDS discovery crosses a network boundary. Deception Check says it found no authoritative evidence of wild exploitation and did not treat traversal-shaped honeypot traffic as proof against this CVE. Neither the Siemens advisory nor the current independent review establishes remote code execution or direct robot-control takeover. Those limits are part of the story.[1,5]

Operator checkpoint

The practical next check is inventory, not a dramatic incident label: identify ROS hosts and workspaces that actually run the file service, update to 2.2.2 or later, remove unnecessary write rights, constrain ROS/DDS and rosbridge reachability, and watch the service account for reads or writes outside the intended package share. The next decision-changing record would be patch coverage, confirmed exploitation, a CISA KEV entry, or telemetry showing attempts against the service. Until then, this is a cyber-physical exposure and remediation gap—not proof that a robot was taken over.[1,2,5]