SUMMARY: For nearly a decade, security researchers have shown that a robot’s physical safety features — the speed limits, force limits, and proximity sensors regulators require — are just software, and software can be rewritten by an attacker. The industry’s response has mostly been to patch each case as it surfaces.
- In May 2017, two independent research teams — IOActive, and Trend Micro working with Politecnico di Milano — separately published findings that industrial robots could be remotely reprogrammed to defeat their own safety limits, undetected by human operators
- In May 2026, researchers disclosed a critical flaw (CVSS 9.8) in Universal Robots’ widely used cobot control software, letting an unauthenticated attacker on the network run commands directly on the robot
- In September 2025, researchers disclosed a wormable Bluetooth exploit affecting Unitree’s entire humanoid and quadruped robot line, using one hardcoded encryption key shared across every unit — letting one compromised robot silently compromise every other one in range
- Independent technical analysis also documented Unitree G1 units transmitting operational telemetry to Chinese-registered servers — a finding researchers frame as a consent and data-governance concern, not confirmed espionage
Two Millimeters, and a Warning About Airplanes
In early May 2017, researchers at Trend Micro and Italy’s Politecnico di Milano ran an experiment on an ABB IRB140, a six-axis industrial robot arm caged and secured behind standard factory safety measures. They fed the robot’s controller a modified configuration file — not a new instruction, just an altered setting — and asked it to draw a straight line. The robot drew a line two millimeters off. Nothing about its physical movement looked unusual to a human watching. A factory floor operator would have no reason to notice.
“Two millimeters doesn’t sound significant,” Trend Micro’s then-VP of cloud research, Mark Nunnikhoven, told Forbes at the time, “but it made a defect in manufacturing. If that was an airplane… it can be a catastrophic event.” In their published scenario, the same technique degraded a 3D-printed drone rotor just enough to cause flight failure — a flaw invisible until the part was already in use.
The Same Month, a Second Team Reached the Same Conclusion
The Trend Micro and Politecnico di Milano findings weren’t an isolated result. That same month, security firm IOActive published its own research, testing more than 50 vulnerabilities across six robot vendors: SoftBank’s NAO and Pepper, UBTECH’s Alpha series, ROBOTIS models, Universal Robots’ UR3, UR5, and UR10, and Rethink Robotics’ Baxter and Sawyer. In one demonstration, IOActive researchers Cesar Cerrudo and Lucas Apa went further than Trend Micro’s team. They gained access to a robot arm’s operating system and directly overwrote the file governing its speed limits, force limits, and proximity-response parameters. The result wasn’t a two-millimeter error. It was a safety-constrained industrial arm operating with no protective limits at all.
Two research teams, working independently, reached the same underlying finding within weeks of each other: a robot’s certified safety behavior isn’t a physical property of the machine. It’s a setting in software, and settings can be changed by anyone with access to the system that stores them.
Nine Years Later, the Same Category of Robot
This isn’t ancient history repeating in a new form. It’s the same specific category of robot, from the same era of research, showing up again. In May 2026, researchers at industrial-security firm Claroty disclosed CVE-2026-8153, a critical vulnerability — CVSS score 9.8 — in PolyScope 5, the control software for Universal Robots’ cobots. The flaw sat in the Dashboard Server, a network interface the robot uses to accept external commands. Universal Robots is one of the six vendors IOActive tested in 2017.
The vulnerability let an unauthenticated attacker with network access send commands that executed directly on the robot’s operating system. Claroty researcher Vera Mens explained why that’s easier to reach than it might sound: many cobots ship with an Ethernet port for legitimate remote management, and the industrial networks those ports sit on are “often flat and lack proper segmentation.” In plain terms, a network without internal walls between systems — the kind common on factory floors, where a robot’s control network and a company’s broader IT network aren’t always cleanly separated. Gaining a foothold anywhere on that network, Mens noted, may not be difficult. Universal Robots patched the flaw in PolyScope 5.25.1.
The Wormable Version
If the 2017 and 2026 industrial-robot cases show the same vulnerability class persisting, the newest research shows it escalating. In September 2025, security researchers Andreas Makris and Kevin Finisterre disclosed an exploit dubbed UniPwn, affecting Unitree’s entire current robot line — the G1 and H1 humanoids, and the Go2 and B2 quadrupeds. The flaw lives in how the robots receive Wi-Fi credentials over Bluetooth Low Energy during setup: the interface doesn’t properly filter what it’s sent, and every unit across the product line shares the same hardcoded encryption key.
That last detail is what makes UniPwn more than an ordinary vulnerability. Because the key is identical across units, a compromised robot can scan for other Unitree robots within Bluetooth range and compromise them automatically, with no user action required. IEEE Spectrum’s Evan Ackerman, reporting the disclosure, called it the first major public exploit of a commercial humanoid robot platform. Robotics security researcher Víctor Mayoral-Vilches, quoted in the same reporting, offered a one-line summary that doubles as a thesis for this entire pattern: “Robots are only safe if secure.”
A Separate, More Carefully Handled Finding
A related piece of research deserves separate treatment because it’s a different kind of claim. Independent researchers analyzing a Unitree G1 unit’s network traffic documented the robot maintaining persistent, continuous connections to servers at two Chinese-registered IP addresses, transmitting operational telemetry — audio, video, and sensor data — roughly every five minutes. The connections used TLS encryption, but the researchers’ own traffic-inspection method captured the data before encryption, revealing what was actually being sent.
What this finding does and doesn’t establish matters. It documents that data leaves the device, where it goes, and how often — verified through direct technical analysis, not assumption. It doesn’t, on its own, establish that this telemetry constitutes state-directed espionage rather than routine device-analytics infrastructure that a company based in China would reasonably route through servers it controls. The researchers who documented it frame the core problem as one of consent and disclosure. Do users of a robot operating in their home, office, or facility know what’s being collected and where it goes? That’s a different, more defensible question than asserting a specific intelligence-gathering purpose, and it’s the framing used here.
Why This Is the Same Story as Robot Safety Regulation, Not a Different One
Every regulatory standard discussed in the physical-safety side of this topic tests a robot’s certified behavior at a point in time. That includes the risk assessments required for fixed industrial robots, the force and pressure limits set for cobots, and even the newer voluntary standards written for autonomous mobile robots. None of them, as written, test whether that certified behavior can be remotely altered after the fact by someone who was never supposed to have access to it.
That’s not a gap in any single standard. It’s a gap in the underlying premise connecting all of them: that a robot passing its safety certification will continue behaving the way it did during certification, indefinitely, regardless of what happens to the software running it. The 2017 IOActive demonstration didn’t need to defeat a safety standard through cleverness. It just needed to change a setting the standard had no mechanism to protect.
What Isn’t Settled
Several things about this pattern remain genuinely open. Public reporting doesn’t establish how many organizations running Universal Robots cobots had actually patched to PolyScope 5.25.1 by the time CVE-2026-8153 became public, or how long the flat, unsegmented networks Mens described have been standard practice versus a known-and-tolerated risk. Unitree’s own remediation timeline for UniPwn is incomplete in the sourcing reviewed here — reporting from late September 2025 described the flaw as unpatched at that point, and this account cannot confirm current patch status without more recent verification.
Whether the vulnerability pattern found in Universal Robots and Unitree systems generalizes to other major manufacturers — Fanuc, ABB, KUKA, Boston Dynamics — at the same severity isn’t established by the sources here. Each of those companies has its own architecture, and an absence of a comparably public disclosure isn’t evidence of an absence of comparable flaws.
One scope note: this account focuses specifically on robots with physical actuation — arms, mobile bases, humanoid and quadruped platforms — and the intersection between their cybersecurity and their physical safety certifications. It doesn’t cover software-only AI agents or robots’ underlying AI model vulnerabilities (prompt injection, adversarial perception attacks), which are a related but distinct research area.
The Standard Nobody’s Written Yet
A robot can pass every physical safety certification that currently exists and still be, at any given moment, one unpatched vulnerability away from operating completely outside every limit it was certified under. That’s been demonstrable since May 2017. It was demonstrated again in 2026, against the same vendor category, and demonstrated a third time in a more severe form against an entirely newer category of robot in between.
None of the regulatory bodies covered in this account’s earlier work on physical robot safety currently require testing for that specific failure mode — a robot’s safety behavior surviving contact with an unauthorized network actor. Cybersecurity and physical safety, in the robots described here, aren’t two problems that happen to share a machine. They’re the same problem, tested by two different disciplines that, so far, mostly haven’t been asked to test together.
