As reported by SecurityAffairs, security researcher Olivier Laflamme has disclosed a chained vulnerability in the Unitree G1 humanoid robot that enables unauthenticated root access without any physical contact — and critically, demonstrates how a single compromised unit could pivot to attack other G1 robots within Bluetooth range.
This disclosure lands at a moment when humanoid robots are transitioning from research curiosities to deployed commercial assets. The G1 is positioned as an affordable, general-purpose humanoid — which means it will likely appear in warehouses, labs, and facilities where security hardening is often an afterthought. The attack chain Laflamme documented is not a theoretical edge case; it exploits fundamental design assumptions about trust boundaries between Bluetooth, cloud APIs, mobile applications, and on-device firmware.
Vulnerability Summary
| CVE | Component | Issue | Impact |
|---|---|---|---|
| CVE-2026-76639 | AI Chatbot Service (On-Device) | Path traversal in “knowledge” file upload allows arbitrary file writes to trusted bashrunner directory | Unauthenticated root-level shell execution via DDS messages |
| CVE-2026-76640 | BLE + Unitree Cloud API | Unpaired BLE write requests bootstrap blob; cloud API decrypts for any logged-in account without ownership verification | Attacker obtains AES-128 key unlocking BLE and WebRTC channels, enabling WiFi config manipulation and remote root |
CVSS scores: Not yet formally assigned at time of reporting. Based on the described chain — unauthenticated, remote, root-level, with potential for lateral movement — Shield53 assesses both flaws individually as High to Critical, and the combined chain as Critical.
Affected product: Unitree G1 humanoid robot (firmware versions prior to patch, if/when issued).
Patch status: No vendor advisory or patch was confirmed at time of writing. Organizations should monitor Unitree's official channels for firmware updates.
Active exploitation: None reported. This is a coordinated research disclosure, not a threat intelligence finding.
Why This Matters Beyond the G1
The most significant architectural problem here is not any single bug — it is the cloud decryption oracle. Unitree's design assumed that because the RSA private key lived server-side, the bootstrap blob was safe to hand over to any nearby Bluetooth device. But the cloud API that decrypted that blob performed no ownership check. Any free Unitree account could submit any robot's encrypted blob and receive the decrypted AES-128 key.
This is a classic broken trust boundary: the security model assumed the cloud would enforce authorization, but the cloud only enforced authentication. Any account could decrypt any robot.
The second concern is wormability. Laflamme demonstrated that once a G1 is compromised, it can be used to attack other G1 units within Bluetooth range. In a warehouse or research facility deploying multiple humanoids in proximity, a single initial compromise could cascade. This is the robotics equivalent of a network worm, but the propagation vector is physical proximity rather than network routing.
Who Is at Risk
Shield53 Recommendations
Immediate Actions
- Disable Bluetooth on deployed G1 units if wireless BLE control is not required for your use case. This removes the initial access vector for CVE-2026-76640.
- Restrict network exposure of the G1's Ethernet interface. CVE-2026-76639 can be exploited over a local network without any wireless chain. Place robots on isolated VLANs with no internet egress unless explicitly required.
- Do not register G1 units under shared or generic Unitree accounts. Use dedicated service accounts and treat Unitree cloud credentials as privileged access.
- Monitor for firmware updates from Unitree. Until a patch is issued, treat these robots as untrusted devices on your network.
Strategic Actions
- Apply network microsegmentation to all robotic and IoT assets. Robots should not share flat networks with corporate workstations or production systems.
- Conduct a robotics-specific security review before any humanoid deployment. Standard IT hardening checklists do not cover BLE trust models, DDS message authentication, or cloud-to-device key exchange protocols.
- Establish a procurement security requirement that mandates vendor disclosure of authentication and authorization models for cloud-connected physical devices — not just encryption-in-transit checkboxes.
The broader industry lesson is clear: as humanoid robots become commercially viable, they inherit every class of vulnerability we have seen in IoT, plus new ones rooted in physical actuation and proximity-based communication. Vendors must treat the robot as a security-critical endpoint, not a consumer gadget with a cloud backend. Until they do, defenders must assume these devices are hostile by default.
