Hack One Robot, Reach the Next: Unitree G1 Security Flaws
Hack One Robot, Reach the Next: Unitree G1 Security Flaws
August 29, 2026 
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)
About Author
