Unitree G1 root RCE over Bluetooth, no pairing needed

A researcher walked into Bluetooth range of a humanoid robot and got root on it without pairing, without credentials, and without touching the network it was on. The Unitree G1 root RCE over Bluetooth disclosure landed 27 August, and the reason it belongs on your reading list has nothing to do with robots. Four of the five bugs in the chain are the same mistakes shipping in ordinary connected hardware — the kiosk in your lobby, the scanner behind your counter, the lock on your back door.

What actually happened

Olivier Laflamme published the research, dubbed UniBLEed, covering two separate root paths on the Unitree G1 EDU's Locomotion PC — the Linux box that runs motors, cameras, audio and voice. Two CVEs were assigned on 20 August.

CVE-2026-76640 is the Bluetooth chain, and it is a five-link failure. GATT characteristic 0xFFE2 accepted writes with bare WRITE permission, so any BLE client in radio range could talk to it with no pairing and no authentication. Opcode 0xF2 returned the device's AES-128 key wrapped with RSA. Unitree's /device/bindExtData cloud endpoint would then decrypt that material for any authenticated account — no ownership check on the robot. With the plaintext key, the attacker configures Wi-Fi through a heredoc injection, then triggers a 1,050-byte buffer overflow via an oversized SSID and lands root. Laflamme reports the chain is wormable: one compromised G1 can infect the next G1 in range.

CVE-2026-76639 is the other path — a directory traversal in the chat_go AI service writes an arbitrary file into bashrunner's whitelist directory, and bashrunner executes it as root.

Credit where it's due: Unitree triaged fast, paid a $5,000 bounty in early August, and had shipped the cloud ownership check and, per the researcher, patches for the large majority of the issues before publication. Testing covered G1 EDU firmware 1.5.1.1 through 1.5.2, and the researcher notes the shared software stack likely reaches other Unitree products.

Why it matters for your business

You are not buying a G1. You are buying BLE-enabled hardware constantly, and the bugs here are the boring ones.

Start with the cloud API. A vendor endpoint that decrypts a device secret for any logged-in account is a missing authorization check — the single most common serious flaw in connected-product backends, and one no amount of firmware hardening fixes. When you evaluate a device, ask the vendor exactly what their cloud will hand out to an account that does not own the device. If they can't answer in one sentence, that is your answer.

Then reset your idea of the perimeter. Your VLAN, your firewall, your VPN — none of it touches an unpaired BLE characteristic. The perimeter for that device is a radius in metres, and it includes the sidewalk. Inventory what in your building advertises over BLE, confirm each vendor has a firmware update channel you can actually reach, and treat "we're on a private network" as an untested assumption rather than a control.

Sources: Olivier Laflamme / boschko.ca, The Hacker News.