Laflamme reused CVE-2026-76639 as a primitive while demonstrating the separate Bluetooth chain [29], and that reuse is the detail that decides exploitability. The G1's memory addresses are randomized, so he turned the path traversal into an information leak, learned where the vulnerable program sat in memory, and used that leak to make the second exploit land reliably [15], with the first bug effectively buying reliability for the second.
The overflow is unsubtle. The Bluetooth server read into a 500-byte buffer with no proper bounds checking, and Laflamme sent 1,050 bytes, which is 550 past the end [13][27], enough to plant a fake cleanup structure that the program later treated as a legitimate function pointer and called with root privileges [14]. Reaching that code path required the robot on his own network first: an oversized Wi-Fi password trips a fallback branch in Unitree's configuration script, which inserts attacker-controlled text into a config file without escaping it, and the robot joins the hotspot it is told to join, with no physical access at any point [12].
The two publishers describe different residual risk. Security Affairs reads the chain as unauthenticated root on any G1 within Bluetooth range [21]. The Hacker News says the bootstrap material itself stays protected and the Wi-Fi provisioning operations require the app's authenticated BLE state [20], and that as of the August 27 disclosure the cloud-assisted route needs an account already bound to the target robot or the key material in hand [19]. Both readings come out of the same three-month project [26]. The gap is whether you are describing the robot before or after July 2026, when Unitree fixed the account-to-robot ownership check [18]. That check was the load-bearing step: the blob is RSA-encrypted and Unitree's cloud holds the private key, which is the boundary the design relied on [7], and during the research a free logged-in account was enough to make the cloud open it for someone else's robot [10][9].
The part an operator cannot close is the firmware. No accessible Unitree guidance names a fixed release for either CVE, so owners have no confirmed release target [22]. The Hacker News says it has asked Unitree to confirm fixed versions, affected product scope and remediation status [23]. The research timeline shows the test robot upgraded to V1.5.2, which does not by itself establish V1.5.1.1 as affected [25]. So the fix you can verify is server-side, and the two paths that execute code on the Locomotion PC have no version number to patch toward [28]. That leaves the Ethernet-side bug fully live for anyone who can reach the robot's services, since it works over five DDS messages with no wireless surface and no authentication required [5][4].
The propagation story has real limits worth stating plainly. Laflamme tested it on two G1 robots in one room, so the reach of a chain reaction across a floor is unmeasured [17]. Unitree's own product page lists the G1 and the G1 EDU as separate models, and whether either CVE applies beyond the EDU is unconfirmed [24].
