Two high-severity flaws in Unitree G1 EDU robots open a path to root-level takeover

Two newly disclosed high-severity vulnerabilities affect Unitree G1 EDU humanoid robots running firmware through version 1.5.2, according to a security write-up published on dev.to. The flaws are tracked as CVE-2026-76639, rated 8.8 on the CVSS scale, and CVE-2026-76640, rated 7.5. Both vulnerability records describe attack paths that, under affected conditions, could end with code executing as root on the robot.

What was disclosed

According to the dev.to summary, the advisories specifically cover the G1 EDU variant of Unitree's compact humanoid, up to and including firmware 1.5.2. The severity of the issue goes beyond a typical device compromise because of what the machine actually is: the G1 EDU carries cameras and depth sensors, microphones, Wi-Fi and Bluetooth radios, a Linux-based compute stack, AI accelerators, developer APIs and SDKs, ROS integrations, and physical motors and actuators. As the write-up points out, that means robot security now sits at the intersection of IoT, endpoint, operational-technology and physical-safety concerns.

CVE-2026-76639: an adjacent-network attack path

The first flaw, with the higher of the two scores at 8.8, involves an attack chain described in the advisory as allowing an unauthenticated attacker on an adjacent network to reach root-level command execution on an affected robot. In practice, that points at whoever shares network space with the machine rather than a remote internet-based actor.

The dev.to post draws a straightforward operational lesson from this: robots used for experimentation should not be granted broad reach into sensitive corporate or campus networks simply because they need LAN or internet connectivity. Network segmentation becomes the baseline control.

CVE-2026-76640: Bluetooth and Wi-Fi provisioning

The second vulnerability, scored 7.5, sits in components associated with Bluetooth Low Energy and Wi-Fi provisioning. The advisory describes conditions that may lead to root-level code execution, and because the vector involves short-range wireless setup processes, being physically near the robot is part of the threat model.

That matters for humanoids specifically. As the dev.to article notes, these robots are commonly operated in laboratories, universities, demonstrations and other settings where many people can walk right up to the hardware, so a proximity-dependent flaw is harder to dismiss than it would be for a server in a rack.

Which robots are actually affected

The advisories identify Unitree G1 EDU firmware through version 1.5.2, and nothing broader should be inferred from them. The dev.to author is explicit on this point: other Unitree platforms such as the G1, H1, H2 or R1 may share software components with the EDU variant, but shared components alone do not prove those models carry the same vulnerability. Exact model and firmware identification is the deciding factor, and operators should verify both before assuming exposure.

Steps for robotics teams

The write-up recommends applying the same security discipline to programmable humanoids as to any other network-connected equipment, and offers a practical checklist: identify the exact robot model, record installed firmware versions, review current manufacturer security advisories, segment robotics equipment from sensitive networks where appropriate, question whether Bluetooth and Wi-Fi interfaces are needed at all, maintain an inventory of firmware and software versions, and assign clear responsibility for applying future security updates.

Why it matters

Humanoid robots are converging with general-purpose networked computing, and that turns each firmware release and wireless interface into a security decision rather than a pure engineering detail. The dev.to piece argues the shift will reach procurement: buyers who today compare payload, degrees of freedom, onboard compute, ROS support and battery runtime will increasingly need to weigh firmware support policies, update processes, network requirements and vulnerability-response procedures before purchase.

For teams already running G1 EDU units, the immediate actions are concrete: confirm the firmware version, check vendor advisories, and isolate the robot from networks it does not need to reach. As humanoids move from research platforms toward commercial deployment, vulnerability management is becoming part of robot engineering itself — not an afterthought bolted on once the machines leave the lab.