Robot Operating System Security Vulnerabilities in Industrial Networks

The Robot Operating System carries security gaps that trace back to explicit design choices made when the framework was built for laboratories, not factories. ROS 1 was designed for research environments where network isolation was the assumed security boundary, so authentication, encryption, and integrity checks were simply never built into its publish and subscribe core. Any process that could reach the network could read any data stream, inject a message, or impersonate a node, all without presenting so much as a password. Researchers demonstrated this at DEF CON 20, showing that the publish and subscribe core at the heart of ROS had no authentication and no integrity checking whatsoever. That demonstration mattered because it confirmed something specific: ROS was insecure by design, not by an oversight someone forgot to patch. Core vulnerability classes follow directly from that architecture: denial of service, unauthorized publishing, and unauthorized data access, each one a direct consequence of a system built to trust every node it heard from.

Some in the field still defend this openness, arguing that stripping out authentication and encryption barriers was what let ROS become the common language of robotics research in the first place. Several manufacturers frame the absence of built-in security controls as a feature that enables system integration, treating tight access control as a burden on interoperability rather than a safeguard worth the friction. This is a real position held by practitioners and vendors. It also has a real cost: when operators believe an open architecture is a design virtue rather than a risk they need to manage, they have little reason to layer on the mitigations that would close the gap. The assumption underneath all of it, that a trusted, isolated network would always stand between a ROS deployment and anyone who meant it harm, worked reasonably well in a university lab, an early confirmation that the framework was insecure by design, not by neglect.

How ROS 2 and DDS shifted the structural problem

SROS2 defines five plugins covering authentication, access control, cryptography, logging, and data tagging, but ROS 2 only implements the first three, leaving logging and data tagging unsupported and creating audit and traceability gaps. Logging and data tagging, the two plugins that would give an operator an audit trail and a way to trace where data came from, are not supported at all. That gap matters at scale, because ROS 2 now accounts for the large majority of all ROS downloads, so a default-insecure posture is not a corner case affecting a handful of hobbyist projects but a condition shared across a fleet-scale share of everything running the framework today.

An operator who believes they are "using ROS 2 security" may in practice be running exposed to replay attacks and unauthorized topic subscriptions. The architecture improved. What ROS 2 delivered was security made possible, not security made automatic, and that difference is the whole story of why the vulnerability moved rather than disappeared.

Even a deployment that gets the configuration right is not finished. Research by Deng et al., presented at ACM CCS, identified three design vulnerabilities that persist even when SROS2 is deployed correctly. V1 is inadequate permission revocation: a node that has been compromised and later has its certificate revoked can, under the wrong conditions, retain access anyway. V2 is inadequate namespace isolation, which allows information to leak across domains without any individual node ever violating its own stated permissions. V3 concerns the discovery protocol that lets ROS 2 nodes find each other on a network, and it exposes the full topology of that network to anyone simply listening, no intrusion required. Layered on top of these design flaws sit independently disclosed vulnerabilities in the DDS layer itself, cataloged separately from anything specific to SROS2. Seven new CVEs against commercial DDS implementations were added to MITRE's database in 2026 alone, continuing a trajectory that a 2021 CISA advisory had already established when it documented multiple CVEs spread across six different DDS implementations. That pace of disclosure means a correctly configured SROS2 deployment is still a moving target, since new implementation bugs keep reopening a surface the operator thought was closed.

The specific attack surfaces these design choices create in industrial networks

The architectural weaknesses described above are not abstractions confined to academic papers. Unauthenticated node communication, misconfigured DDS deployments, and default-open installations combine to produce a set of distinct, demonstrated attack surfaces inside real industrial ROS environments.

The most direct is man-in-the-middle interception and message injection. Because unauthenticated ROS topic communication carries no integrity checking, a malicious node can intercept messages passing between legitimate nodes, alter them, and republish them as if nothing happened. Researchers demonstrated exactly this in ROS-based IoT systems built on Jetson Nano hardware, showing how quickly an attacker who inserts a single malicious node can compromise data traveling through what looked like a closed system.

A second, quieter attack class exploits timing rather than content. SlowROS takes advantage of ROS's potentially endless connection timeout, letting an attacker block an entire production pipeline without needing any meaningful bandwidth. The attack has been validated on a real multi-component network, where it left ROS components unable to operate correctly and measurably disrupted a production pipeline. It works precisely because it is low-noise: the traffic pattern it produces looks like ordinary latency, not an attack in progress.

A third surface concerns partially secured deployments rather than fully open ones. In SROS2 installations where access control policies are incomplete, unauthorized nodes can subscribe to sensitive topics they were never meant to see, or replay previously captured command sequences back onto the network. This is the practical, operational expression of the discovery protocol vulnerability that Deng et al. identified: a passive attacker can learn the complete node and topic graph of a system without ever sending a malicious packet, and use that map to plan a far more targeted intrusion later.

None of this requires an attacker to be anywhere near the factory. The Aztarna footprinting tool identified thousands of ROS and industrial robot endpoints reachable on the open internet, spanning both ROS 1 and ROS 2 installations that remain live and exploitable today. And the physical layer carries its own version of the same problem: a 2026 study documented LiDAR spoofing attacks capable of crashing or freezing ROS 2-based unmanned ground vehicles, a sensor-level attack that converts directly into a loss of physical control over the machine.

What industrial compromise looks like: three demonstrated cases

Three documented cases show these attack classes translating into actual compromise of production systems, and each illustrates a different point of entry.

The first is Akerbeltz, a ransomware strain built and demonstrated between 2019 and 2020 by Víctor Mayoral-Vilches and colleagues at Alias Robotics, recognized as the first known instance of ransomware targeting an industrial robot. The demonstration ran against controllers from Universal Robots, a leading name in collaborative robotics. The attack sequence was straightforward once access was gained: take control through the exposed controller, lock the robot, encrypt its stored programs and intellectual property, and bring production to a halt. Akerbeltz matters because it demonstrates what a ROS compromise actually costs an operator. The endpoint is not stolen data sitting on a server somewhere, but a stopped production line and proprietary automation logic held for ransom.

The second is a 2025 supply chain attack, demonstrated by Severov and colleagues. Trojanized versions of the command-line packages were shown capable of exfiltrating keystore credentials through covert DNS queries issued during the routine process of creating a keystore or enclave. This case matters because it breaks a common assumption: an operator can follow every SROS2 configuration step correctly, generate certificates properly, write sound access policies, and still lose the keys, because the tooling used to set everything up was poisoned before installation ever began. Stolen credentials do not just leak data. They let an attacker's node join an otherwise "secure" DDS graph and be treated as legitimate, because it holds certificates the system has no reason to doubt.

The third is Xiaomi CyberDog, an open-source robotics platform built on ROS 2 Galactic and running Cyclone DDS. The product shipped with publicly reported default SSH credentials, username "mi" and password "123". LLM integration into ROS control pipelines and demonstrated supply chain attacks on SROS2 tooling have opened attack surfaces that the existing DDS Security and SROS2 framework was not designed to cover. It shows how a manufacturer's decision to prioritize easy access at the product level can undercut whatever protection the middleware underneath is capable of providing.

Taken together, the three cases share a single thread. In none of them did the attacker need to break any cryptography. Each one found a way through missing authentication, a default password left unchanged, or a poisoned piece of software sitting upstream of the security layer.

Why a ROS breach differs from IT network compromise

A compromised database server leaks records. A compromised industrial robot can hurt someone. In industrial ROS deployments, a security breach is simultaneously a safety event: because ROS systems are coupled directly to physical machinery, a compromised robot can cause injury, destroy equipment, or halt production in ways a compromised server cannot.

Consider what these machines actually do. A compromised robot can weld, lift, drive, or work in direct proximity to a person, and the consequence of a security flaw in that context is not exposed data but potential injury or death. The exposure is rarely confined to a single unit. Survey respondents reported that a disruption to ROS could affect more than five robots simultaneously in a substantial share of cases. A single point of compromise can carry a blast radius across an entire fleet in a networked industrial environment. A separate survey of quadruped robots put numbers to the physical stakes: a 50 kilogram robot moving at speed carries kinetic energy sufficient to cause severe injury in an uncontrolled collision, and a communication delay of just 50 milliseconds can cause the robot to miss a swing-to-stance transition while climbing stairs. Deployment contexts for these systems, industrial inspection, military reconnaissance, emergency response, increasingly sit inside critical infrastructure, where malicious control over even one unit can trigger cascading failures across a facility.

A second dimension compounds the physical stakes: securing a ROS system costs performance. Enabling SROS2's security features increases latency and reduces throughput, and that cost creates real pressure on operators to switch security off in applications that depend on real-time response. A systematic review of ROS 2 confirmed the trade-off is measurable, finding that adding security features produces a quantifiable drop in system performance. The trade-off is not hypothetical even when security stays enabled. SlowROS showed that an attacker can induce an effective denial of service against a production pipeline simply by exploiting timeout behavior, without ever touching or disabling the security configuration itself.

The emerging attack surface that current defenses do not yet cover: LLM-mediated control and supply chain insertion

Two recent developments, large language models entering ROS control pipelines and demonstrated supply chain attacks against SROS2 tooling, have opened up attack surfaces that DDS Security and SROS2 were never built to address.

A 2026 study by Xie and Wei-Kocsis examined LoRA-based supply chain backdoors embedded in LLM-mediated ROS 2 robotic control systems, testing them in both simulation and on real hardware. The backdoored models the study produced achieved a high average attack success rate while still performing well on clean, legitimate tasks and responding in under a second, making the attack both effective and difficult to notice during normal operation. A defense built around a second LLM verifying commands from the first cut the attack success rate substantially, but it pushed end-to-end latency out to 8 to 9 seconds, reintroducing the security-responsiveness trade-off in a form real-time robotic control cannot tolerate.

The Severov demonstration, described earlier as a case of endpoint compromise, confirms a broader shift: an attacker unable to break network-layer security can instead poison the tooling used to configure that security in the first place. Put alongside the LLM backdoor research, the pattern is the same. A "correctly secured" ROS 2 deployment now has to account for the integrity of its software supply chain, a category of risk that the DDS Security specification does not cover at all. Both of these newer attacks show how that assumption breaks.