SURIQ
A humanoid robot is a Linux computer with legs, sitting on your Wi-Fi, that nobody on your security team is watching. That gap is the real story behind two attacks disclosed on August 27, 2026 against the Unitree G1 EDU, a research robot in the $20,000 to $40,000 range that is showing up in labs, universities, and a growing number of workplaces. Security researcher Olivier Laflamme published two independent chains that each end in full root control of the robot's main control computer: one reachable over the local network, one reachable over Bluetooth from across a room.
The two chains carry the identifiers CVE-2026-76639 and CVE-2026-76640, and neither needs a password. The first abuses the robot's built-in AI chat feature; the second abuses its Bluetooth setup path. Laflamme reported both to Unitree, which paid a combined $5,000 bounty and moved quickly on the part it could fix in its cloud. The parts that live in the robot's firmware are, by the researcher's account, the harder and slower fix.
How each flaw reaches root
The network chain, CVE-2026-76639, starts with the G1's AI chat service. It lets a user upload knowledge files, and it barely checks the filename. A path-traversal write drops a file into a directory the bashrunner service trusts. A handful of control messages restart bashrunner, the planted file runs as root on the robot's Locomotion PC, and the attacker has a shell. No account is required; the attacker only needs to reach the robot on the network.
The Bluetooth chain, CVE-2026-76640, is the one that should worry an operator more, because it needs no network foothold at all, only proximity. An unpaired device asks the robot for its encrypted key material over Bluetooth. That blob is protected with an RSA key that only Unitree's cloud can open, so the phone app forwards it to Unitree to be decrypted. From there the chain reaches a buffer overflow in the Bluetooth server: a Wi-Fi password field that should hold a few dozen bytes accepts a 1,050-byte payload against a 500-byte buffer, and a separate information leak defeats the memory-address randomization that would otherwise make the overflow unreliable. The result is attacker-controlled code running as root.
The cloud oracle is the lesson, not the buffer overflow
The overflow is the dramatic part, but the weakness that actually matters is quieter. According to Laflamme's disclosure, to hand back a robot's key material, Unitree's cloud decrypted that RSA-protected blob for any logged-in account, without checking that the account actually owned that robot. The design assumed that holding the private key was the security boundary. It was not. Any free account could recover the key for a G1 it had never touched, and that single key unlocked both the Bluetooth channel and the robot's WebRTC signaling.
This is the part worth carrying to your own architecture, whether or not you will ever own a robot. When a device offloads its authorization decision to a vendor's cloud API, it inherits that vendor's access-control bugs as your compromise. The robot did nothing wrong locally; a missing ownership check on a server you do not run was enough to reach root on hardware in your building. Every connected product that provisions itself through a manufacturer cloud carries the same dependency, and it is almost never in the threat model.
Why one hacked robot becomes many
Laflamme showed the Bluetooth chain is self-spreading. Once one G1 is compromised, that robot can run the same attack against other G1 units within Bluetooth range, with no additional discovery or setup. He tested it on two robots in one room. In a warehouse, a teaching lab, or a campus running dozens of identical units, that is the difference between one incident and a chain reaction, and the shared cloud key material is what makes every unit reachable the same way.
The stakes are not abstract. In his writeup, the researcher notes that a compromised G1 could be used to watch and listen through its cameras and microphones, tamper with its onboard perception and movement models, and disable safety checks such as collision detection on a roughly 90-pound machine. A networked appliance that can physically move is a different risk class from a hijacked printer, even if the entry technique rhymes with one.
A Linux endpoint your tools do not see
Strip away the novelty and the pattern is familiar. This is an unmanaged Linux endpoint on your network that your endpoint agent does not run on, your patch cycle does not reach, and your asset inventory probably does not list. It is the same blind spot that turned thousands of IP cameras into an attacker's swarm and car head units into proxy infrastructure, and it is the same Bluetooth-proximity setup weakness that recently let a nearby attacker hijack DJI drones. The device you forgot to inventory is the one that gets you, as the operators of one quietly recruited router found out. When defenders cannot see a host, they cannot detect what happens on it; CISA's red team made that point the hard way when it lived inside two critical-infrastructure networks that produced little telemetry from the systems it used. Extending host-level detection and inventory to every device that runs an operating system, not just the servers and laptops you provision, is the point of an XDR approach that watches the whole fleet.
What Unitree fixed, and what you still cannot patch
Unitree earned real credit for its response. It closed the cloud ownership check within roughly two months of the report and paid the bounty, and the researcher described the coordination as close to ideal. But the fix that shipped is the server-side one. The unpaired-Bluetooth writes and the buffer overflow sit deeper in the firmware, and there is no confirmed fixed firmware build for either chain in Unitree's public guidance at the time of writing. That is the window you have to manage: the flashy remote takeover is the part you currently cannot patch away.
| Weakness | Chain | Fix status at disclosure |
|---|---|---|
| Cloud decrypts key material without an ownership check | Bluetooth (CVE-2026-76640) | Patched cloud-side by Unitree, mid-2026 |
| Unpaired Bluetooth writes plus buffer overflow to root | Bluetooth (CVE-2026-76640) | Firmware fix pending, described as slower |
Chat service path traversal to bashrunner | Local network (CVE-2026-76639) | No fixed firmware build confirmed in vendor guidance |
Isolate the robot before you power it up again
The first move is network separation, because it is the control you fully own. Put every G1 on its own segment or Wi-Fi network, away from production systems, user devices, and anything holding data. Since the worst chain needs Bluetooth proximity, treat physical and radio access as part of the perimeter: limit who can get within range while a robot is powered on, and power units down when they are not in use rather than leaving them idle and reachable. Add each robot to your asset inventory with its firmware version, so you can act the moment Unitree ships a firmware fix. Where you can capture it, watch the robot's host for the tells of this attack: a unit suddenly joining an unknown Wi-Fi network or hotspot, or reaching out to an address it has never contacted. The cloud weakness is already closed on Unitree's side, so no action is needed there, but the firmware exposure is yours to contain until a build exists to close it.