Wormable Robot Vulnerability Raises Fleet Security Concerns

A reported remote-code vulnerability in Unitree robots has raised an uncomfortable but important question: what happens when a robot is not just hackable, but potentially able to help compromise other robots nearby?

The discussion centres on a vulnerability affecting Unitree robot lines including Go2, G1, H1 and B2. The issue is described as command injection through the Bluetooth Low Energy Wi-Fi configuration path, with malicious configuration data allowing commands to run as root. In plain English, that means an attacker could potentially get the robot to run unauthorised commands with very high privileges.

The more striking part is that researchers describe the flaw as wormable. A wormable vulnerability is one that can spread from one vulnerable device to another without each victim needing to click a link, install an app or approve a prompt. For robots, that matters because the device is not just a screen on a desk. It has radios, sensors, software, movement and sometimes a role in a physical workspace.

Why a wormable robot flaw is different from an ordinary gadget bug

We are used to thinking about compromised smart devices as privacy or nuisance problems. A hacked camera might expose video. A hacked router might become part of a botnet. A hacked robot, however, can combine several risk categories at once.

Unitree’s own Go2 product page presents the robot as a mobile quadruped platform with wireless connectivity and app-based features, which is exactly the sort of connected device that needs to be treated as part of a broader security environment rather than a novelty purchase: Unitree Robotics Go2.

The practical risk is cyber-physical. A compromised robot may affect confidentiality through onboard sensors, availability by disrupting a fleet, and safety if movement or actuation is abused. That does not mean every robot becomes dangerous overnight. It does mean that robots deserve the same sober risk management already applied to laptops, servers, industrial controllers and building access systems.

What remote code execution and root access mean

Remote code execution, often shortened to RCE, means an attacker can cause a system to run code or commands from outside the normal trusted workflow. Root access is the highest privilege level on many Unix-like systems. If a vulnerability allows commands to run as root, the attacker may have broad control over the device.

In this case, the reported path involves Bluetooth Low Energy, commonly used for setup and nearby device communication, and Wi-Fi configuration. That combination is worth noting because it shifts attention from internet-exposed dashboards to local radio proximity. A robot may be vulnerable even if it is not deliberately exposed to the public internet.

The exact real-world spread rate, ease of exploitation in every environment and current patch status for each affected deployment are not disclosed in the discussion source. Sensible readers should avoid both panic and complacency. The right response is verification.

UK home users should treat robots as high-risk smart devices

For home users, the concern is simple: a connected robot sits inside your private space. If compromised, it could become a surveillance device, a network foothold or a physical nuisance. That is especially relevant where robots have cameras, microphones, mapping functions or autonomous movement.

The UK context matters here. The Product Security and Telecommunications Infrastructure regime has applied from 29 April 2024 and sets baseline requirements for relevant consumer connectable products, including rules around passwords, vulnerability reporting information and minimum security-update period information. UK buyers should read that as a procurement checklist, not just a regulatory footnote: UK Product Security and Telecommunications Infrastructure regime.

Before buying a robot dog or humanoid platform for home use, ask how long security updates will be provided, whether default passwords are prohibited, and whether the supplier has a clear vulnerability disclosure process. If those answers are vague, that is a signal.

Labs and universities need to include robots in vulnerability management

Robotics labs often connect robots to research Wi-Fi, development laptops, ROS or DDS systems, datasets, cameras and credentials. That creates a richer attack surface than a typical consumer gadget. A compromised robot may become a bridge between nearby radio access, robot control software and institutional networks.

This is where vulnerability management becomes a day-to-day operational discipline. The National Cyber Security Centre recommends that organisations monitor update status, prioritise fixes and segregate high-risk or unsupported devices where they cannot be upgraded. That guidance applies neatly to robot fleets: NCSC vulnerability management guidance.

For a university or lab, the practical controls are not exotic. Put robots on isolated lab VLANs. Avoid storing reusable credentials on robot images. Log robot network activity. Include robots in penetration testing scopes. Make kill procedures part of testing, not an afterthought.

This also connects to a wider shift in robotics. As I have written before, the move from clever demos to general-purpose robots brings messy real-world dependencies, including training workflows, hardware constraints and support models. The same theme appears in the push towards more capable robotic hands and general-purpose robots. Capability is only useful if the surrounding system is trustworthy.

Warehouses should manage robot fleets like operational technology

For warehouses, logistics centres and industrial sites, a wormable robot vulnerability can become a business continuity issue. The main concern may not be cinematic robot chaos. It may be downtime, misrouting, internal reconnaissance or a fleet becoming unavailable during a busy fulfilment window.

That is why mobile robot fleets should be managed more like operational technology than office peripherals. They need segmentation, documented update procedures, controlled vendor access and clear ownership. If a robot depends on cloud services, apps, local controllers and wireless links, each dependency needs to be understood.

A good rule of thumb: one compromised robot should not be able to talk freely to every other robot, every warehouse system and the corporate network. If the network design assumes all robot traffic is trusted, the design is doing too much hoping.

Procurement questions UK buyers should ask before deployment

The most useful lesson is not limited to Unitree. Any organisation buying connected robots should make security part of procurement, not a post-purchase scramble. These are reasonable questions to ask suppliers, importers and integrators:

• Is this model affected by CVE-2025-35027 or related Bluetooth Low Energy remote-code issues?
• Which firmware and app versions remediate the issue?
• Is there a public security advisory and a vulnerability disclosure contact?
• Can Bluetooth setup be disabled or restricted after commissioning?
• Are updates signed and protected against rollback?
• Are cryptographic keys unique per device?
• Does developer or user code run in a sandbox, rather than as root?
• Can logs be exported to existing monitoring or SIEM tools?
• What is the minimum security-update support end date?
• Who is responsible for emergency patching in the UK supply chain?

These questions may feel blunt, but they are not unreasonable. If a robot is mobile, connected and expensive enough to be used in a business process, it is important enough to have a security lifecycle.

What to do now if you already use connected robots

First, identify the exact model, firmware branch and companion app version. Do not assume that over-the-air updates mean the device is safe. Record what is installed, when it was updated and whether the update succeeded.

Second, isolate the robot. Use a dedicated VLAN or SSID, restrict outbound internet access to documented vendor services, and block robot-to-robot traffic unless it is genuinely required. Treat Bluetooth as part of the attack surface, particularly in public demos, shared labs or mixed-fleet environments.

Third, decide what to do if a fix is unavailable. That might mean powering down radios, removing the robot from sensitive networks, limiting demonstrations or accepting a documented residual risk for a short period. The worst option is leaving the robot connected because nobody owns the decision.

Finally, widen the conversation. Robot security is not only a job for the IT department. It involves facilities, health and safety, procurement, legal, research teams and operations. The more physical the system becomes, the more cross-functional the risk becomes.

Robot security is becoming an operational discipline

This vulnerability is a useful warning because it collapses the distance between cybersecurity and the physical world. A robot is software, hardware, sensors, radios and movement wrapped into one system. If it can be compromised remotely and potentially used to reach nearby devices, it must be governed accordingly.

That does not mean UK homes, labs and businesses should avoid robotics. It means the security model has to mature as quickly as the hardware. Patch where possible, isolate by default, verify supplier claims before purchase and manage robots throughout their lifecycle.

The future of robotics will not be decided only by dexterity, autonomy or price. It will also be decided by whether organisations can trust fleets of machines to operate safely, update reliably and fail gracefully when something goes wrong.