SINGAPORE, 29 AUG 2026 — A security researcher has published two root remote code execution chains against the Unitree G1 EDU humanoid robot, one of which begins over Bluetooth Low Energy without pairing. The headline is that anyone in Bluetooth range can take over the robot. The part that made that possible was in Unitree's cloud, and it was fixed in July.

What has not been confirmed fixed is the code on the robot itself.

The two chains

Olivier Laflamme disclosed the findings on 27 August, tracked as CVE-2026-76639 and CVE-2026-76640. Both end in root execution on the robot's Locomotion PC, which is the computer that controls how the machine moves.

CVE-2026-76639 is network-adjacent. A path traversal flaw in the knowledge-base upload used by the chat_go AI service allows a file to be written into the whitelist directory read by a component called bashrunner, which then executes it. A feature for uploading documents to an assistant becomes a way to run commands as root.

CVE-2026-76640 is the chain that starts with Bluetooth. An initial BLE write is accepted without pairing, but the exploitable buffer overflow sits in the Wi-Fi provisioning code, which requires an authenticated BLE state. The cloud service was the path to that state.

Two CVEsCVE-2026-76639 and CVE-2026-76640
RootOn the Locomotion PC, in both chains
July 2026When the cloud ownership check was fixed
Not verifiedNo confirmed fixed firmware release for the device itself

The actual defect was an authorisation check

During the research, Unitree's cloud service accepted a key-recovery request from any valid Unitree account without verifying that the account owned the robot named in the request. An attacker with an ordinary account could therefore recover key material belonging to somebody else's G1 EDU.

That key material is what supplied the authenticated BLE state, which in turn allowed the researcher to reach the Wi-Fi provisioning buffer overflow and obtain root.

The memorable framing — root over Bluetooth, no pairing needed — describes the entry point accurately and understates the rest of the chain. The break was a missing ownership check on a server, one of the most common categories of web application flaw, that happened to sit underneath a robot.

What is fixed and what is not

Unitree patched the cloud ownership check in July 2026, and the researcher confirms that this breaks his specific proof of concept. The cloud-assisted route to key material now requires the account to be bound to the target device, or the attacker to hold key material already.

The buffer overflow is a separate matter. As of the 27 August disclosure, no fixed firmware release had been verified in any accessible Unitree guidance. The overflow is in code that runs on the robot, and a server-side fix does not remove it — it removes one way of reaching it.

That distinction matters for any G1 EDU owner. If you have physical access to a robot, or an account legitimately bound to it, or key material obtained by any other means, the vulnerable code path is still there. The cloud fix raised the bar for a stranger. It did not remove the flaw.

Cloud dependency is the pattern here

The structural lesson here is not about Bluetooth or buffer overflows, both decades-old problems. It is that a robot's security now depends on a web service the owner has no visibility into.

The G1 EDU calls home for key recovery, which is a reasonable design: losing access to an expensive machine because a laptop died would be worse. But it means the device's trust boundary extends to a server the owner does not run, cannot audit and is not told about when it changes. When the ownership check on that server was wrong, every robot depending on it was reachable, and no amount of hardening on the robot would have mattered.

The dependency also cuts the other way. Because the flaw was server-side, Unitree could fix it for every customer at once without shipping firmware, without a recall and without anyone applying an update. Very few embedded security problems can be closed that quickly. The dependency that created the exposure also allowed Unitree to reduce it with a single server-side deployment.

Read the model number carefully

There is a trap for anyone searching this topic. A separate Bluetooth vulnerability in a Unitree G1 was reported in October 2025, and it is a different disclosure from this one.

Coverage of the two overlaps enough that a reader can easily conclude the 2026 CVEs are a rehash, or that the 2025 issue has been fixed by the July cloud patch. Neither follows. Anyone assessing exposure should work from the CVE identifiers rather than from headlines, which in this area are close to interchangeable.

Laflamme also notes that applicability to other Unitree models is unconfirmed. The findings are against the G1 EDU, tested with two robots in one room, and should not be assumed to extend across the range without evidence.

Why this matters more than a usual CVE

Root on a laptop means an attacker reads your files. Root on the Locomotion PC of a humanoid robot means an attacker controls a machine that moves through a physical space where people are standing.

The G1 EDU is sold into universities and research groups, environments with many devices and few security operations. There is generally no endpoint agent, no patch management and nobody whose job it is to notice.

The timing sharpens the point. Unitree listed on the STAR Market this month and rose 460 per cent on debut against 8,000-times oversubscription. A company being valued on the assumption that humanoid robots enter workplaces at scale has just been shown to have shipped an unauthenticated path to root, and to have had a missing ownership check in the cloud service those robots depend on.

Owners should restrict these machines to isolated networks, treat the chat_go upload feature as an untrusted input path, and ask Unitree for the specific firmware version that fixes CVE-2026-76640. The cloud fix is not a complete answer.