Two chained flaws reach root on Unitree's G1 humanoid from Bluetooth range
Olivier Laflamme walked an unpaired Bluetooth write up to root on the G1 EDU's Locomotion PC by way of a Unitree cloud API that decrypted key material for any logged-in account. Unitree fixed that check in July, but no patched firmware has been named.
The Watch · Security desk
What happened
- Olivier Laflamme published two independent root code execution chains against the Unitree G1 EDU humanoid on August 27, 2026, tracked as CVE-2026-76639 and CVE-2026-76640.
- CVE-2026-76639 abuses a knowledge upload in the robot's chat_go service that barely validates filenames, planting a file in a directory bashrunner trusts and returning root with five DDS messages.
- CVE-2026-76640 opens with a Bluetooth write that needs no pairing to pull the robot's encrypted bootstrap blob, which Unitree's cloud then decrypted for an account that did not own that robot.
- An oversized Wi-Fi password overflows a stack buffer in the G1's Bluetooth server, and that is where the chain turns into command execution as root on the robot's Locomotion PC.
- Unitree patched the cloud account-to-robot ownership check in July 2026, and Laflamme says that fix breaks the exact proof-of-concept flow he demonstrated.
Why it matters
- Who's exposed exposure Wormability makes the unit count the blast radius: a compromised G1 can run the same attack on neighbours in Bluetooth range with no fresh discovery, so a floor with dozens of them sits one hop from the first one.
- What it limits constraint With no fixed firmware release named for either CVE, owners have nothing to write on a patch ticket, and containment falls back to proximity control and keeping the robot's DDS services off any network a stranger can reach.
- Who has to decide decision Anyone piloting these robots now has to decide whether they accept hardware whose authentication boundary sits in a vendor cloud API rather than on the device, because that is where the key custody lived.
Laflamme reused CVE-2026-76639 as a primitive while demonstrating the separate Bluetooth chain [18], and that reuse is the detail that decides exploitability. The G1's memory addresses are randomized, so he turned the path traversal into an information leak, learned where the vulnerable program sat in memory, and used that leak to make the second exploit land reliably [21], with the first bug effectively buying reliability for the second.
The overflow is unsubtle. The Bluetooth server read into a 500-byte buffer with no proper bounds checking, and Laflamme sent 1,050 bytes, which is 550 past the end [11][28], enough to plant a fake cleanup structure that the program later treated as a legitimate function pointer and called with root privileges [12]. Reaching that code path required the robot on his own network first: an oversized Wi-Fi password trips a fallback branch in Unitree's configuration script, which inserts attacker-controlled text into a config file without escaping it, and the robot joins the hotspot it is told to join, with no physical access at any point [20].
The two publishers describe different residual risk. Security Affairs reads the chain as unauthenticated root on any G1 within Bluetooth range [24]. The Hacker News says the bootstrap material itself stays protected and the Wi-Fi provisioning operations require the app's authenticated BLE state [23], and that as of the August 27 disclosure the cloud-assisted route needs an account already bound to the target robot or the key material in hand [15]. Both readings come out of the same three-month project [17]. The gap is whether you are describing the robot before or after July 2026, when Unitree fixed the account-to-robot ownership check [14]. That check was the load-bearing step: the blob is RSA-encrypted and Unitree's cloud holds the private key, which is the boundary the design relied on [7], and during the research a free logged-in account was enough to make the cloud open it for someone else's robot [10][9].
The part an operator cannot close is the firmware. No accessible Unitree guidance names a fixed release for either CVE, so owners have no confirmed release target [16]. The Hacker News says it has asked Unitree to confirm fixed versions, affected product scope and remediation status [25]. The research timeline shows the test robot upgraded to V1.5.2, which does not by itself establish V1.5.1.1 as affected [27]. So the fix you can verify is server-side, and the two paths that execute code on the Locomotion PC have no version number to patch toward [29]. That leaves the Ethernet-side bug fully live for anyone who can reach the robot's services, since it works over five DDS messages with no wireless surface and no authentication required [5][4].
The propagation story has real limits worth stating plainly. Laflamme tested it on two G1 robots in one room, so the reach of a chain reaction across a floor is unmeasured [22]. Unitree's own product page lists the G1 and the G1 EDU as separate models, and whether either CVE applies beyond the EDU is unconfirmed [26].
What to watch
- Unitree's answer to The Hacker News on fixed firmware versions, affected product scope and remediation status.
- Whether either CVE applies beyond the G1 EDU to the non-EDU G1 or other Unitree models.
- An advisory naming an affected firmware baseline, since the research only documents an upgrade to V1.5.2.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence72
- Adoption38
- Hype gap+8
- Incentives45
- Confidence62
Perspective Coverage
4 publishers- Builder
- Builder 38%
- Operator
- Operator 50%
- Investor
- Investor 12%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Security researcher Olivier Laflamme disclosed two independent root remote code execution chains affecting the Unitree G1 EDU humanoid, published August 27, 2026.
- [2]
The flaws are tracked as CVE-2026-76639 and CVE-2026-76640; the first is a network-adjacent path through chat_go and bashrunner, the second begins from BLE proximity.
- [3]
CVE-2026-76639 uses a path-traversal condition in chat_go to reach bashrunner, and execution through bashrunner results in root code execution on the Locomotion PC.
- [4]
The G1's AI chatbot service accepts a knowledge upload with almost no validation of the filename it writes, letting a path traversal payload write an arbitrary file anywhere, including a directory the bashrunner service treats as trusted; restarting bashrunner and telling it to run the planted file yields root-level shell execution with five DDS messages and zero authentication.
- [5]
The first bug lives entirely inside the robot and needs no wireless attack surface if the attacker can reach the robot over Ethernet.
- [6]
For CVE-2026-76640, the initial BLE write path accepts the bootstrap interaction without Bluetooth pairing.
- [7]
An unpaired device can request the robot's encrypted key bootstrap blob; the blob is RSA-encrypted and the corresponding private key is held by Unitree's cloud infrastructure, which Laflamme describes as the security boundary Unitree appears to have relied on.
- [8]
The Unitree mobile app reassembles the BLE notification chunks and POSTs them to Unitree's cloud API endpoint /device/bindExtData on global-robot-api.unitree.com, storing the response body as gcmKey.
- [9]
During Laflamme's research, Unitree's cloud service accepted a valid Unitree account for the key-recovery request but did not verify that the account owned the supplied robot, allowing the account to recover key material associated with another G1 EDU.
- [10]
Unitree's cloud API would decrypt the bootstrap blob for any free, logged-in Unitree account without checking whether the account owned that specific robot.
- [11]
The G1's Bluetooth server used a 500-byte buffer without proper bounds checking, and Laflamme overwrote nearby memory with a crafted 1,050-byte payload.
- [12]
The payload created a fake cleanup structure that the program later interpreted as a legitimate function pointer, causing it to execute an attacker-controlled command with root privileges.
- [13]
Once an attacker compromises one G1, that robot can use the same attack against other G1 robots within Bluetooth range without requiring additional discovery or configuration.
- [14]
Laflamme said Unitree patched the cloud account-to-robot ownership check in July 2026.
- [15]
As of the August 27 disclosure the cloud-assisted route requires an account bound to the target G1 or the relevant key material already in hand, and Laflamme said the cloud authorization fix breaks that exact proof-of-concept flow.
- [16]
An exact fixed firmware release has not been verified in any accessible Unitree guidance, leaving G1 EDU owners without a confirmed release target for either vulnerability.
- [17]
Laflamme spent about three months investigating the Unitree G1 humanoid robot.
- [18]
Laflamme described CVE-2026-76639 as an independent RCE but reused it as one disclosure primitive while demonstrating the separate BLE chain tracked as CVE-2026-76640.
- [19]
Laflamme's report states the single AES-128 key unlocks both the BLE protocol and the WebRTC signaling channels.
- [20]
An oversized Wi-Fi password triggers a fallback code path in Unitree's own configuration script that inserts attacker-controlled text into a config file without escaping it, letting the attacker force the robot to join a hotspot they control with no physical access.
- [21]
Memory addresses were randomized, so Laflamme first turned the first vulnerability into an information leak to discover where the vulnerable program was loaded and make the second exploit work reliably.
- [22]
Laflamme limited his propagation test to two G1 robots in the same room, so the real-world reach of a chain reaction remains unclear.
- [23]
The Hacker News reports that the bootstrap material itself remains protected and the later Wi-Fi provisioning operations require the application's authenticated BLE state.
- [24]
Security Affairs reports that the two vulnerabilities can be chained across Bluetooth, Unitree's cloud infrastructure, the mobile app and the robot's firmware to gain unauthenticated root access to any G1 within Bluetooth range.
- [25]
The Hacker News says it has contacted Unitree to confirm the fixed firmware versions, the affected product scope and the current remediation status.
- [26]
Unitree's official product page distinguishes the G1 and G1 EDU as separate models, and broader applicability of the two vulnerabilities to other Unitree robots remains unconfirmed.
- [27]
The research timeline shows Laflamme upgraded the test robot to V1.5.2, but that sequence does not by itself establish V1.5.1.1 as affected.
- [28]
The 1,050-byte payload wrote 550 bytes past the end of the 500-byte buffer.
- [29]
The only vendor fix documented in the disclosure is server-side, and neither of the two code-execution paths on the Locomotion PC has a confirmed firmware version to patch toward.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
4 independent publishers whose own reporting we read for this story.
- Olivier Laflamme
boschko.ca
1 article · August 30, 2026
- scworld.comTwo root remote code execution flaws found in Unitree G1 EDU robot
1 article · August 28, 2026
- securityaffairs.comHack One Robot, Reach the Next: Unitree G1 Security Flaws
1 article · August 29, 2026
- thehackernews.comTwo Unitree G1 EDU Humanoid Robot Flaws Enable Root RCE, One Starts Over Bluetooth
2 articles · August 29, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Humanoid RobotsFollow
- Remote Code Execution SurfacesFollow
- Bluetooth Low Energy SecurityFollow
- Robot and Humanoid SecurityFollow
- Coordinated Vulnerability DisclosureFollow