Wormable Robot Hack Turns a Lone Bug into a Fleet-Wide Breach

The thing that made me write this

A single tweet from security researcher Lukasz Olejnik earlier this week summed up a story I've been watching since last September: “One compromised robot could infect other vulnerable robots nearby, turning a single breach into a wide compromise. Could attackers then take control of entire fleets?”

That's not a hypothetical. It's a documented capability in commercial robots you can buy today — and it's already escalated from a researcher's notebook to a national security supply-chain decision. Here's what happened, in plain terms, and what it means for anyone running connected machines with legs.

The flaw: one Wi-Fi setup button handed over the whole robot

In September 2025, security researchers Andreas Makris and Kevin Finisterre disclosed a vulnerability they named UniPwn (tracked as CVE-2025-35027, rated 7.3 High). It affects several of Unitree's commercially available robots — the Go2 and B2 quadrupeds, and the G1 and H1 humanoids.

The attack went through an innocuous feature: the Bluetooth Low Energy (BLE) channel the robots use to let you configure Wi-Fi during setup. That provisioning service was, in effect, the front door to administrative access. The chain of mistakes that made it exploitable is almost textbook:

• Hardcoded crypto keys. Every affected device shipped with the same AES key and IV, baked into the firmware.
• Trivial authentication. The “handshake” essentially just checked that you sent the string unitree encrypted with that known key.
• Command injection. The Wi-Fi SSID and password fields were passed, unsanitized, into shell commands running with root privileges.

String those together and a nearby attacker on the wireless network doesn't just get in — they get rooton the robot. The researchers' proof-of-concept rebooted a robot remotely. The same access would let an attacker implant persistent malware that survives restarts, exfiltrate anything the robot senses or stores, or silently block future firmware updates.

The part that's actually scary: it's wormable

Here's the detail that pushed this from “one vulnerable gadget” to “fleet problem”:

Because the compromised device itself carries the exploit, an infected robot can scan for other vulnerable Unitree robots within BLE range and compromise them the same way — autonomously, with no human clicking anything. That's the definition of wormable: a breach that propagates robot-to-robot, capable in principle of becoming a self-replicating botnet of physical machines.

A fair caveat, which the researchers and most reporting were careful to include: wormable in the lab is not the same as guaranteed rapid spread in the real world.Whether it actually propagates depends on how the robots are configured, how the network is segmented, firmware diversity, physical proximity, and how fast operators patch. But “unlikely to go pandemic tomorrow” is cold comfort when the capability is real and the exposure is physical.

Disclosures didn't stop the story — they widened it

What makes this worth revisiting now is that September's disclosure was not the end. Unitree was contacted in May 2025, stopped responding to the researchers in July, and the finding went public in September. Since then, independent teams kept digging into a firmware base the whole product line shares:

• UniTEABag (Feb 2026): the firmware's encryption was broken, opening up the update and signing process.
• Two more remote-code-execution bugs (Feb 2026): CVE-2026-27509 (an unauthenticated DDS-based RCE — the robot's internal publish-subscribe bus accepts arbitrary Python with no authentication in its default config) and CVE-2026-27510 (tampering with the companion app's database to make code run persistently). Unitree pushed OTA patches in firmware V1.1.13 to address the latter.

Then, in July 2026, the escalations stopped being only about code. The U.S. FCC added foreign-produced mobile robots to its Covered List, explicitly citing these Unitree flaws (CVE-2025-35027/UniPwn and CVE-2025-2894, a separate remote-control bug in the Go1 quadrupeds). The practical effect: new models lose the equipment authorization needed to be imported, marketed, or sold in the U.S.

That's the arc in three acts: a wormable bug → more bugs in the same family → a regulator treating the class of device as a supply-chain risk.

The so-what

For anyone running, buying, or building autonomous machines, this is less a story about one Chinese robot brand and more a lesson about what physical autonomy does to security.

Physical autonomy amplifies ordinary mistakes. A hardcoded key, a joke of a handshake, and unsanitized input would be a bad day for a Wi-Fi router. Bolted to a robot that moves, senses, and now carries an on-device AI brain, the same three mistakes become something that can take over a physical asset and spread to its neighbors.

“Robot security is an IT problem” is a dangerous framing. When an attacker gets root on a robot, they aren't just reading data — they can change what the robot's AI sees, decides, and does.That's not an infrastructure issue; it's an engineering requirement for anyone deploying physical systems into workplaces, homes, or public space.

If you're buying AI hardware, you're buying a software supply chain.The security of the thing you deploy is the sum of its firmware keys, its update pipeline, its undocumented network services, and a vendor's willingness to respond to researchers. Procurement ought to be part of the security program.

The close

Practical and grounded, for our readers who own or operate these platforms:

• Patch. Keep robot firmware current — several of these bugs were addressed via OTA, and old versions remain exposed.
• Segment the network. Don't put robots on the same flat network as everything else. BLE provisioning and the internal control bus should both be treated as attack surface.
• Assume proximity is a vector. “An infected robot can reach things in BLE range” reframes how you think about what's physically allowed near a fleet.
• Match the purchase to a security posture. If you deploy autonomous hardware, review what firmware controls the vendor actually gives you, and what their disclosure record looks like before you buy, not after.

The wormable claim in that tweet wasn't alarmism — it was a documented feature of the platform, and it's already influenced policy. Treat connected robots the way you'd treat any internet-connected system with authority over the physical world: as something that will be attacked, and engineer for it from day one.

Sources: NVD — CVE-2025-35027 (UniPwn) · UniPwn disclosure (GitHub) · NVD — CVE-2026-27509 · NVD — CVE-2026-27510 · FCC — Robots added to Covered List · Mayer Brown analysis · TechTimes coverage