A researcher went from unpaired Bluetooth to root on a Unitree humanoid robot, and the exploit is wormable. AI is getting a body with IoT-grade security

What was found

The same week Anthropic previewed a standard for letting AI agents drive physical devices, a security researcher published what happens when the physical device is a humanoid robot and nobody did the security. On 27 August 2026, Olivier Laflamme disclosed two independent root remote-code-execution chains in the Unitree G1 EDU humanoid robot, CVE-2026-76639 and CVE-2026-76640, one of them reachable over unpaired Bluetooth from across a room.

This is a different category of finding from a chatbot jailbreak. Root here is not on a server, it is on the Locomotion PC, the computer that drives the robot’s motors. And the Bluetooth chain is wormable: one compromised robot can infect the next in range.

2

root RCE chains

Two independent ways to root the robot, CVE-2026-76639 and CVE-2026-76640.

5

bugs in the Bluetooth chain

An unpaired write, a key leak, a cloud oracle, a shell injection and a buffer overflow.

~15

cloud secrets exposed

Production API, app-signing and JWT keys reachable once you have root.

10-100m

Bluetooth range

No account for the robot, no pairing, just proximity for the initial write.

Unpaired Bluetooth to root

The Bluetooth chain (CVE-2026-76640) is the one to understand, because every link in it is an ordinary mistake.

Unpaired Bluetooth to root on a humanoid robot

A nearby attacker writes to a Bluetooth characteristic (0xFFE2) that was registered with no pairing required. A bootstrap opcode (0xF2) hands back the robot’s AES-128 key, wrapped in RSA. On its own that wrapping would protect the key, except for the pivot: Unitree’s own cloud endpoint, /device/bindExtData, will unwrap that blob for any free authenticated account, because it never checked that the account owned the robot whose serial you supplied. With the key in hand, the attacker forces the Wi-Fi provisioning script into an unsafe fallback where an unquoted heredoc becomes a shell injection, then overflows a 500-byte wifi_ssid buffer with a 1050-byte write to corrupt function pointers, and lands as root.

The five bugs, none of them exotic

The Bluetooth root chain, step by step

Step	The flaw
1. Unpaired GATT write	Characteristic 0xFFE2 is writable with no Bluetooth pairing
2. Key disclosure	Opcode 0xF2 returns the robot AES-128 key, RSA-wrapped
3. Cloud oracle	The bindExtData endpoint unwraps that key for any free account, with no ownership check
4. Shell injection	A crafted PSK forces wpa_connect.sh into an unsafe heredoc fallback
5. Buffer overflow	A 1050-byte write into a 500-byte wifi_ssid buffer corrupts pointers to reach root

The pivot worth staring at is step three. The key was properly encrypted, and the attacker simply asked the vendor’s cloud to decrypt it, and the cloud obliged because it authenticated the requester and never checked the ownership. It is the same shape this site keeps finding: a trust boundary that verifies one thing and quietly assumes another.

It is wormable

The second way in

The other chain (CVE-2026-76639) needs only network adjacency. The robot’s AI knowledge-upload feature has a path traversal that writes outside its directory:

# the "knowledge upload" writes here, escaping its own folder...
../../../../../unitree/module/bashrunner/content_acquisition/

# ...into bashrunner, which sh-executes files from that directory as root,
# extension-agnostic, off a whitelist it builds once at import. Drop a file, run as root.

Two different front doors, chat_go over the network and btgatt-server over Bluetooth, both ending as root on the same Locomotion PC.

What root on a robot means

This is where a robot stops being a laptop with legs and becomes its own risk class.

What root on the robot reaches

Root gave control of the motors and actuators and access to the cameras and microphones, which is the part with no software equivalent: an attacker can make the machine move, and can watch and listen through it. It also exposed production keys for services like AWS Polly, iFlytek and DashScope, roughly fifteen high-impact secrets including app-signing and JWT keys sitting in the robot’s object storage, and a pivot onto the internal 192.168.123.0/24 network. One robot, owned from across a room, is a moving camera, a live microphone, a bag of cloud credentials and a foothold on the LAN.

The pattern, and the timing

The lesson is not that this vendor is uniquely careless. It is the timing. AI is being given a body just as this research shows the bodies are secured like 2015 IoT: an unpaired Bluetooth write, a cloud that decrypts a key for anyone who asks, a shell injection in a provisioning script, a textbook stack overflow. Each of those has been a solved problem in server software for a decade. On a machine that walks, they are new again, because the industry building the machines is, in Laflamme’s words, largely not hiring for security roles.

Credit where it is due, and it matters. Unitree fixed the cloud ownership check in July 2026, before disclosure, and paid a bounty, and Laflamme praises the responsiveness of its security team. This is disclosure working. But the cloud fix closes one link; a robot still answering unpaired Bluetooth writes with a key-leaking opcode is a body waiting for the next chain.

The disclosure, start to finish

1. 2 to 10 May

   First root RCE found

   The chat_go path traversal into bashrunner is discovered and demonstrated.

2. 14 May

   Vendor confirms

   Unitree verifies the first chain.

3. 21 May

   Cloud oracle identified

   The bindExtData endpoint is found to unwrap keys without an ownership check.

4. 25 Jun

   Bluetooth chain confirmed

   The full unpaired-Bluetooth-to-root chain is proven end to end.

5. 1 to 6 Jul

   Cloud fix shipped

   Unitree adds an account-to-robot ownership binding on the cloud endpoint.

6. 27 Aug

   Public disclosure

   Both chains disclosed, CVEs assigned, a $5,000 bounty paid.

What to do

The position

For a decade, the worst case for a compromised device was that it leaked data or joined a botnet. A humanoid robot raises the ceiling. Rooted from across a room over a Bluetooth interface that never asked for pairing, a G1 becomes a machine an attacker can drive, see through and hear through, that also happens to be carrying the fleet’s cloud keys, and that can spread the same compromise to the next robot it stands near. The individual bugs are boring. Their setting is not.

The honest reading is that the software industry spent twenty years learning to secure servers, and the robotics industry is now shipping bodies that run the same mistakes with actuators attached. The right response is not alarm about robots, it is the ordinary discipline applied early: isolate them, scope their credentials, secure every local interface, and treat a machine that can move as exactly what it is, an actuated computer that will be attacked like every computer before it. AI getting a body does not change the security work. It raises the stakes of skipping it.