Siemens documents unauthenticated arbitrary file read and write in the ROS# file_server service, and rates it CVSS v4.0 9.3. The fixed release shipped on 22 April 2026, before the advisory. What changed on 25 August is that an independent public proof-of-concept appeared demonstrating the read path. That lowers the effort required to test this flaw. It is not, on its own, evidence that anyone is exploiting it.
file_server service shipped with Siemens ROS#, the open-source library set that connects .NET and Unity applications to the Robot Operating System. The service builds a file path from an untrusted name without reliably keeping the result inside the named ROS package's share directory. Siemens documents arbitrary file read and write with the rights of the account running the service, requiring no credentials and no user interaction from a party who can reach the service. Siemens rates it 9.3 under CVSS v4.0 and 9.1 under v3.1. The fix shipped in ROS# 2.2.2 on 22 April 2026; the coordinated advisory followed on 12 May, and CISA republished it as ICSA-26-134-08 on 14 May. On 25 August 2026 an independent public proof-of-concept appeared demonstrating the read path across hosts. We reviewed it statically and did not execute it. As of publication the CVE is absent from the CISA Known Exploited Vulnerabilities catalog and no authoritative source we checked reports exploitation in the wild.ROS# is Siemens' open-source set of libraries and ROS packages for connecting .NET and Unity applications to the Robot Operating System. The vulnerable component is the ROS file_server service, which transfers URDF-related robot description files. It exists in both the ROS 1 file_server package and the ROS 2 file_server2 package, and both received the fix. Siemens' own advisory names the service file_server.
The distinction matters for scoping. The service runs on a ROS host. A workstation that merely uses a ROS# client is not automatically the vulnerable component, so the inventory question is which ROS hosts and workspaces actually deploy the service, not which machines have the library installed.
The usual ROS# launch starts both the file service and rosbridge_websocket, and Siemens notes that its normal asynchronous WebSocket communication is unencrypted. But the vulnerable component is a ROS service, not a standalone WebSocket endpoint, and the public PoC reaches the ROS 2 service directly over DDS. Containment that covers only WebSocket exposure is therefore incomplete.
This is worth stating plainly because the sequence is easy to get backwards. Siemens published ROS# 2.2.2 on 22 April 2026. The changelog for that release gates saving behind new allow_save and allow_overwrite parameters, both defaulting to false, and adds canonicalized path checking. The coordinated advisory SSA-357982 followed on 12 May, and CISA republished it verbatim as ICSA-26-134-08 on 14 May, associating it with the Critical Manufacturing sector. The August event is the arrival of public proof-of-concept material, four months after a fixed release was available.
Siemens' advisory summary documents read and write with the rights of the service account. Read access could expose configuration, robot description files, integration scripts, credentials, or anything else that account can reach. Write access could alter accessible files where saving is enabled; what that enables next depends entirely on the files, the permissions, and how downstream software consumes them.
Neither the advisory nor the current public PoC documents or demonstrates remote code execution or direct robot-control takeover. That is a real boundary and we will not inflate past it. It is also not a guarantee that an arbitrary write can never be chained into something larger. The defensible claim is the narrow one: direct file read and write are vendor-confirmed; more severe outcomes have not been established.
A public proof-of-concept tells you how much effort an attack now takes. It does not tell you whether anyone has bothered.
Siemens states that ROS# is intended for trusted local networks. That is a deployment assumption, not a mitigation. The CVSS vector is still network-reachable, with low complexity, no privileges and no user interaction: a trusted LAN satisfies a network attack path perfectly well. Internet exposure is neither required nor implied.
The practical risk concentrates where an affected ROS service is reachable from an untrusted segment, where ROS and DDS discovery cross intended boundaries, or where an attacker already has a foothold inside the engineering network. The PoC author describes a cross-host ROS 2 lab reproduction between two machines sharing a ROS_DOMAIN_ID; we reviewed it statically and did not execute it. If accurate, that would count against reading this as a local-only problem. CISA associates the advisory with Critical Manufacturing, but deployment context still determines whether any particular organisation is exposed.
A public PoC is not the same as confirmed exploitation, and the two get conflated constantly. The live CISA KEV catalog, latest version 2026.08.25, contains no entry for CVE-2026-41551. CISA's May SSVC record marked exploitation as none, but that assessment predates the August PoC and should not be read as current proof of absence. NVD still lists the CVE as awaiting analysis and is republishing Siemens' scores as a secondary source rather than having assigned its own. No vendor or CERT reporting we checked describes exploitation in the wild.
We re-ran a transparent query across 38 raw HTTP log files from four Deception Check decoy deployments. The window spans 10 April 13:19 UTC through 24 April 01:27 UTC and contains 24,564 parsed requests from 2,346 distinct source IPs, with zero parse errors.
Classification concatenated the request path, query string and body, applied URL decoding up to three times, and counted a request once when the decoded text contained a parent-directory traversal token. Traversal-shaped requests appeared on all 15 UTC calendar dates in the window. Forty-four of the classified requests also referenced /etc/passwd. In 126 of them the traversal token was percent-encoded rather than sent in the clear, meaning it only became visible after decoding.
One result is worth noting, with its limits stated. We routinely have to strip commercial and research scanners — Censys, Shadowserver, Shodan, Cortex Xpanse and others — from first-party counts before they mean anything. As a first-pass check we compared the 107 traversal sources against the address prefixes of those known scanner operators and found no matches. That is a coarse prefix comparison, not a run of our full classifier, and scanners that operate outside their published ranges would not be caught by it. We report it as a preliminary indication that this slice is not dominated by the usual scanner traffic, not as a cleaned adversarial count.
file_server service or the ROS/DDS transport this CVE uses. We checked the decoded request material for rosbridge, file_server/get_file, file_server/save_file, package://file_server, ros-sharp, ros# and siemens, and found no matches. Zero matches means only that this dataset contains no CVE-related HTTP signal. It does not measure ROS activity anywhere else. The window is also April 2026, well before the August PoC, so it is a baseline of technique prevalence rather than a response to this event.We publish no source addresses, no raw request strings and no payloads, and we infer no attribution from IP addresses. An earlier internal draft of this analysis cited 634 traversal requests from 113 sources, a roughly 6,000-source edge-probing figure and a 2.4x edge-to-OT crossover. Those did not reproduce under a documented rule against the available evidence, so they were removed rather than published.
file_server or file_server2. Do not assume every .NET or Unity client is the affected component; many are not.| CVE | CVE-2026-41551, Siemens ROS# file_server relative path traversal, CWE-23, CVSS v4.0 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N), CVSS v3.1 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). Both scores are Siemens CNA assessments; NVD is awaiting analysis and republishes them as secondary |
| Product | All Siemens ROS# versions before 2.2.2. The affected component is the ROS file_server service (ROS 1 file_server, ROS 2 file_server2), not every ROS# client |
| Mechanism | An untrusted file name is used to build a path without reliably constraining the result to the named ROS package's share directory. A reachable, unauthenticated party can read files outside that directory and, where saving is enabled, write outside it. Access is bounded by the rights of the service account |
| Fixed | ROS# 2.2.2, published 22 April 2026. Restricts accepted paths and file types, checks canonicalized paths, and gates saving behind allow_save and allow_overwrite, both defaulting to false |
| Exploitation | Not in the CISA KEV catalog (latest version 2026.08.25, checked at publication). CISA's SSVC record of 12 May 2026 marked exploitation none, predating the August PoC. An independent public read PoC repository was created 25 August 2026 and reviewed statically, not executed. No authoritative confirmation of exploitation in the wild |
| Credit | Alifia Rahmah of VyPr AI, via coordinated disclosure, per Siemens SSA-357982 |
| Advisories | Siemens SSA-357982 v1.0, 12 May 2026. CISA ICSA-26-134-08, republished 14 May 2026, Critical Manufacturing sector. CISA's republication is explicitly verbatim |
| Mitigations | Update to 2.2.2 or later; inventory hosts deploying the service; restrict ROS/DDS and rosbridge reachability; least-privilege the service account; monitor the process account for reads and writes outside the package share directory |