Hack One Robot, Reach the Next: Unitree G1 Security Flaws
Researcher chained two Unitree G1 flaws (CVE-2026-76639, CVE-2026-76640) to gain unauthenticated root access, with compromised robots able to infect others via Bluetooth.
Security researcher Olivier Laflamme chained a path-traversal file-write flaw (CVE-2026-76639) in the G1 chatbot service and a Bluetooth server buffer overflow (CVE-2026-76640) to achieve unauthenticated root access remotely. The chain abuses Unitree's cloud API as a decryption oracle for the AES-128 key that unlocks BLE and WebRTC channels, and a compromised robot can propagate the attack to nearby G1 units. Unitree patched the cloud ownership-check flaw, paid a $5,000 bounty, and firmware fixes for BLE pairing and the buffer overflow remain harder to deliver.
- CVE-2026-76639: path traversal in chatbot knowledge upload enables arbitrary file writes
- CVE-2026-76640: 500-byte buffer overflow in Bluetooth server yields root shell
- Unitree cloud API leaked AES key decryption without verifying robot ownership
- Compromised robots can re-attack other G1 units in Bluetooth range
- Vendor patched cloud check within two months; $5,000 bounty paid
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-76639 | Unauthenticated Root RCE Chain in Unitree G1 EDU Robot Firmware Unitree G1 EDU firmware through version 1.5.2 contains an unauthenticated remote code execution flaw that chains three weaknesses: an unauthenticated WebRTC-to-DDS bridge on TCP port 9991, a static AES-128 key stored with world-readable permissions, and a path traversal flaw (CWE-22) in the chat_go knowledge upload API. A network-adjacent attacker can publish DDS control messages over the bridge to restart the bashrunner service, use the path traversal to plant a malicious payload in the bashrunner script execution directory, and then trigger its execution as uid 0. Because commands run as root, an attacker gains full control of the robot's operating system, not just its motion controls. All operators running G1 EDU firmware at or below 1.5.2 are affected, particularly those with port 9991 reachable from shared or wireless networks. Exploitation has not yet been observed: there is no public proof-of-concept, the flaw is not in CISA KEV, and EPSS estimates only a 0.7% chance of exploitation in the next 30 days. Do: Check your G1 EDU firmware version and update to a patched release from Unitree as soon as one is available beyond 1.5.2. Until then, restrict access to TCP port 9991 by isolating the robot on a dedicated lab VLAN or firewalling the port, and inspect the bashrunner script execution directory for unexpected planted files. | 8.7 | <1% |
| nichelow tens of thousands of G1-series robots deployed worldwide, with the EDU-firmware subset likely in the thousands-to-tens-of-thousands range (no authoritative… | ||
| CVE-2026-76640 | Unauthenticated Root RCE via BLE in Unitree G1 EDU Firmware ≤ 1.5.2 Unitree G1 EDU firmware through version 1.5.2 chains two flaws—an unquoted heredoc variable in the WiFi provisioning script and an out-of-bounds write in the SSID chunk accumulator of the BLE GATT/WiFi provisioning stack—that require no pairing, credentials, or user interaction. An unauthenticated attacker within BLE range sends crafted BLE GATT writes that overflow a fixed BSS buffer across BLE connections, corrupting an adjacent mainloop function-pointer dispatch entry. When the cleanup path later invokes the corrupted entry, attacker-controlled data is passed to system() as uid 0, giving the attacker root code execution on the robot (CVSS 4.0: 7.7 High, adjacent attack vector). Only operators of Unitree G1 EDU humanoid robots running firmware 1.5.2 or earlier are affected. No public proof-of-concept is known, the issue is not in CISA KEV, and EPSS estimates only a 0.3% chance of exploitation in the next 30 days, so exploitation status is currently none known. Do: Check the firmware version on G1 EDU units and upgrade to the first firmware release after 1.5.2 once Unitree publishes a fix. Until then, reduce BLE exposure by keeping untrusted people and devices out of Bluetooth range of the robots and disabling or supervising BLE-based WiFi provisioning. Monitor Unitree advisories, since no public PoC or known exploitation exists today. | 7.7 | <1% |
| nicheunknown, but plausibly on the order of thousands to low tens of thousands of G1 EDU robots deployed worldwide |
Full article1,064 words · extracted from securityaffairs.com · click to collapse

A researcher chained two Unitree G1 flaws to gain root access remotely and showed how a compromised robot could attack others nearby.
Security researcher Olivier Laflamme spent about three months digging into the Unitree G1 humanoid robot and eventually found a way to fully compromise it without plugging in a single cable. In his technical write-up, he details two vulnerabilities, CVE-2026-76639 and CVE-2026-76640, that 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.
The first bug lives entirely inside the robot itself, no wireless attack surface needed if you can reach it over Ethernet. The G1’s AI chatbot service accepts a “knowledge” upload with almost no validation on the filename it writes to disk, and a classic path traversal payload lets an attacker write an arbitrary file anywhere on the filesystem, including into a directory that a separate service called bashrunner treats as trusted. Restart bashrunner, tell it to run the newly planted file, and you’ve got root-level shell execution with five DDS messages and zero authentication.
The second chain is the one that should worry anyone deploying these robots at scale. It starts with a Bluetooth characteristic that accepts writes without pairing, something The Hacker News also covered in its own report on the disclosure. An unpaired device can request the robot’s encrypted key bootstrap blob, and Unitree’s cloud API would decrypt that blob for any free, logged-in Unitree account without ever checking whether the account actually owned that specific robot.
“The blob is RSA-encrypted & the corresponding RSA private key is held by Unitree’s cloud infrastructure. This, in theory, is safe.. This is the security boundary Unitree appears to have relied on. Nearby devices can request the bootstrap blob, but only Unitree owns the RSA private key capable of opening it.” reads Laflamme’s report. “However, the Unitree mobile app reassembles the BLE notification chunks and slingshots that shit via a POST to Unitree’s cloud API /device/bindExtData on global-robot-api.unitree.com and the app stores the response body as gcmKey.”


That decryption oracle is the crux of the whole chain, and Laflamme doesn’t undersell how convenient it made everything.
“This single AES-128 key unlocks both the BLE protocol and the WebRTC signaling channels.” continues the report.
Once an attacker has obtained it, they can authenticate to the robot’s Bluetooth handshake and unlock WiFi configuration commands that were previously locked behind that same key. From there, an oversized WiFi password triggers a fallback code path in Unitree’s own configuration script that inserts attacker-controlled text directly into a config file without escaping it, letting the attacker force the robot to join a hotspot they control, no physical access needed at any point.
Going from “the robot connects to my Wi-Fi” to a full root shell required a buffer overflow in the G1’s Bluetooth server, and this is where the research gets particularly impressive. The server used a 500-byte buffer without proper bounds checking, allowing Laflamme to overwrite nearby memory with a carefully crafted 1,050-byte payload. He used that payload to create 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.
There was one more obstacle: randomized memory addresses. To make the exploit work reliably, Laflamme first needed to discover where the vulnerable program was loaded in memory. He solved that by turning the first vulnerability into an information leak and using the result to make the second exploit work. In other words, one bug effectively helped unlock the other.
The wormability is what turns this from an interesting security flaw into a much more serious operational risk. 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.
Laflamme tested the technique on just two robots in the same room, so the real-world reach of a chain reaction remains unclear. In a warehouse, laboratory, or campus where dozens of these robots operate close to each other, however, the possibility of one compromised machine spreading the attack to others is difficult to ignore.
Unitree’s response gets genuine credit in the writeup, and it’s worth noting given how often vendor disclosure stories go badly. The company patched the cloud ownership-check flaw within about two months of the report, paid out a combined $5,000 bounty across both chains, and worked through verification quickly enough that Laflamme calls the collaboration close to ideal.
“July 1-6 August, 2026 — Unitree implemented an account-to-robot cloud binding ownership check before returning the AES-128 key. Patching the “cloud-oracle” vulnerability discovered back in May. “August 6, 2026 — a $5,000 USD bounty was paid out, $4,000 for the BLE RCE and $1,000 for the chat_go RCE.”
The BLE pairing and buffer overflow issues themselves, notably, sit deeper in the firmware and represent a harder, slower fix than a simple cloud-side ownership check.
None of this required exotic tools or some cutting-edge attack technique. That is probably the detail that should get the most attention from anyone who still sees robot security as a niche problem.
This was a $20,000 humanoid robot, the kind increasingly used in research labs and universities and likely to appear in more workplaces, compromised with a decompiled Android app, a firmware encryption scheme that researchers had already broken years ago, and a familiar class of buffer overflow that predates humanoid robots by decades.
If your organization has a G1 sitting in a lab, lobby, or workspace, checking its patch status should be a priority. A 90-pound robot losing its collision-detection capabilities is not the kind of security incident you want to discover the hard way.
“You could use the G1 to spy on people through audio and video, make it say obscene shit in public, swap out or backdoor the ResNet onboard AI models, tamper with perception and movement logic, disable collision detection and other safety checks (it weighs ~90lbs having that run into a kid, a wall, or even step on your toe will do some serious damage).” concludes the researcher. “They also cost a lot! I’d be pissed off if someone hacked into my G1, took control of it, and walked it off my factory/campus.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Robot)
Text extracted automatically; images, tables and formatting may be missing. Original: https://securityaffairs.com/198085/hacking/hack-one-robot-reach-the-next-unitree-g1-security-flaws.html