Two CVE records published August 27 describe unauthenticated root code execution on the Unitree G1 EDU humanoid, one of them reachable from Bluetooth range with no pairing — and neither the CVE records, the assigning CNA, nor Unitree names a firmware version that fixes it.
What happened
On Thursday, August 27, 2026, security researcher Olivier Laflamme published a technical writeup of two remote code execution chains in the Unitree G1 EDU humanoid robot, along with a proof-of-concept toolkit on GitHub. NVD published both CVE records the same day at 8:18 p.m. UTC. VulnCheck is the assigning CNA for both.
CVE-2026-76639 carries a CVSS 3.1 base score of 8.8 and a CVSS 4.0 base score of 8.7, both supplied by VulnCheck. NVD’s record describes “an unauthenticated remote code execution vulnerability that allows network-adjacent attackers to execute arbitrary commands as root by chaining 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 in the chat_go knowledge upload API.” The researcher adds the last step: files written through the knowledge-base upload are executed by a service whose command whitelist is evaluated only once, at import time.
CVE-2026-76640 is scored 7.5 on CVSS 3.1 and 7.7 on CVSS 4.0. VulnCheck titles it “Unitree G1 EDU 1.5.2 BLE GATT RCE via WiFi Provisioning Stack” and describes chained flaws that “allow unauthenticated proximate attackers to achieve root code execution without pairing or credentials.” The chain runs five links deep: a Bluetooth Low Energy characteristic that accepts writes with no authentication requirement, retrieval of the device’s RSA-wrapped AES key, a cloud API that decrypted and returned that key without verifying the requester owned the robot, an unquoted heredoc variable in the WiFi provisioning path, and a buffer overflow in the SSID chunk accumulator that overruns a 500-byte buffer and corrupts a function pointer.
Both VulnCheck advisories give affected versions as “G1 EDU <= 1.5.2.” Neither names a patched version. Both CVE records carry an NVD vulnStatus of Received, meaning NVD has not yet performed its own analysis and the CNA’s scores are the only ones that exist.
This is single-researcher work on a single product line, covering four G1 EDU units running firmware 1.5.1.1 and 1.5.2. The robot lists at roughly $20,000 and sells primarily into universities, research groups, and industrial pilots. There is no public count of how many are deployed, and this page does not estimate one.
Unitree’s role was not adversarial. The researcher’s timeline records the robot arriving on April 29, 2026, the first chain working by May 10 and verified by Unitree on May 14, the second completed June 25 and validated June 30, a $5,000 bounty paid August 6, and CVE requests filed August 18. He describes the vendor’s security team as “were awesome to work with” and notes that “Unitree was already aware of some of these issues internally.” Unitree implemented at least one fix in that window: “an account-to-robot cloud binding ownership check before returning the AES-128 key.”
Why it matters
The most useful thing here is not either chain individually. It is that the highest-leverage repair was made in a cloud backend, and the rest was not made anywhere an owner can see.
Consider what the ownership check fixed. The BLE chain did not break because Bluetooth is insecure; the designers knew the transport was open and layered encryption on top of it. It broke because the key for that encryption could be obtained by asking a cloud API for it, and the API answered without checking whether the asker owned the robot. That is an authorization bug in a web service, and Unitree fixed it server-side. No owner had to do anything. No owner could have done anything. No owner can verify it was done, roll it back, or confirm which robots it covers. For a class of device where firmware updates are slow, physically inconvenient, and sometimes skipped entirely, the vendor’s ability to repair the important link centrally is a genuine advantage, and it should be counted as one.
It is also why the silence on firmware is the operative finding. The unquoted heredoc variable, the SSID buffer overflow, the DDS bridge on port 9991, the path traversal in the upload API, and the whitelist evaluated only at import time are all defects in code running on the robot. Fixing the cloud ownership check removes one link from one of the two chains. It does not touch the others. An owner reading these records today learns that firmware through 1.5.2 is vulnerable, that a working toolkit is published, and that there is no version number above 1.5.2 named by anyone as the fix. There is nothing to write on a change ticket. Searching for a Unitree security advisory turns up coverage of the research and no vendor page. The Hacker News reports it asked Unitree to confirm fixed firmware versions and affected scope and had not received an answer.
The provisioning path is the recurring lesson, and it is not specific to robots. Any device set up out of the box has to accept its first configuration over a channel that cannot be authenticated, because no credential exists yet. That bootstrapping path is unauthenticated by construction — the hardest surface in the product to get right and, judging by how often it fails, one of the least reviewed. A BLE characteristic accepting bare writes is not itself the bug; it is the design premise. The bug is what the code behind it does with what it receives, and here it accumulated attacker-controlled SSID chunks into a fixed buffer without bounding them.
Then there is what root on this device reaches. A humanoid robot is a Linux computer with a real-time kernel, microphones, cameras, and limbs, standing in a room with people in it; the security and safety questions stop being separable. The researcher also found production third-party API credentials on the robot’s locomotion computer — keys for cloud speech synthesis, voice recognition, and music services from several providers — so root on one robot reaches the vendor’s paid accounts with third parties, a billing and abuse exposure that extends past both the owner and Unitree. An API signing secret was likewise hardcoded in the vendor’s Android app; the literal value is in the published writeup and is not reproduced here, because it offers a defender nothing.
Finally, the researcher’s own framing deserves to be carried rather than dropped, because it is the honest one and because coverage tends to strip it. He states plainly that the work is “a point-in-time account of the platform as I found it during the research and disclosure period, not as a description of its current security posture.” Between June and now, Unitree may have shipped firmware that closes some or all of these paths. Nothing published says so. The gap between “may have been fixed” and “was fixed in version X” is the entire distance between a security program and hoping.
What to do
There is no fixed firmware version to give, because none has been published. If you operate G1 EDU units, ask Unitree directly for the release that remediates CVE-2026-76639 and CVE-2026-76640 and for the models and branches in scope. Until that answer exists, treat every unit as affected.
Put the robots on an isolated segment with nothing else of value on it, and do not treat them as trusted hosts. The first chain reaches the device from an adjacent network position, and TCP port 9991 is the named entry point — it should not be reachable from any general-purpose user network. Both records score the attack vector as adjacent rather than network, so segmentation is a real control here, not a token one.
Treat physical Bluetooth range as part of the perimeter. The second chain needs proximity and no credentials, so the control surface is who can get close to the robot and when it is powered on. Powering units down when not in use reduces exposure and costs nothing.
Rotate any credential a robot has held or could have observed. If your units were provisioned before Unitree’s cloud ownership check went in, treat the AES key protecting the BLE setup channel as having been obtainable by anyone who asked.
Sourcing note
Checked: the NVD records for CVE-2026-76639 and CVE-2026-76640, which supplied the publication timestamps, the CNA identity, the description text, and every CVSS vector and score quoted here; VulnCheck’s advisories for both identifiers, which supplied the titles and the “G1 EDU <= 1.5.2” affected-version string and confirmed no patched version is named; the researcher’s writeup at boschko.ca, which supplied the disclosure timeline, tested firmware versions, bounty amount, and vendor-response quotations; and the public GitHub repository holding the proof-of-concept toolkit, which confirms the artifacts are inspectable.
Single-source limitations, stated plainly: this is one researcher’s work on four robots of one model. The vulnerability details have been validated by the vendor per the researcher’s timeline and accepted by a CNA, but there is no independent reproduction and no second research team. The deployed population is unknown and is not estimated above.
Could not reach: any Unitree security advisory. Searches surfaced no vendor bulletin, no firmware release note referencing either CVE, and no Unitree PSIRT page. That is an absence, not a claim that Unitree has said nothing privately to customers.
Unresolved: which firmware release, if any, fixes the on-device defects, and whether the cloud-side ownership check applies to previously provisioned units or only to new bindings. Neither CVE appears in the KEV catalog as of publication, and no party has reported exploitation in the wild.
