- The Mess: Researchers disclosed two separate root-RCE chains affecting the Unitree G1 EDU, including one that starts over Bluetooth Low Energy. The vulnerabilities are tracked as CVE-2026-76639 and CVE-2026-76640. The BLE attack can reach root on the robot’s Linux-based Locomotion PC without Bluetooth pairing.
- The Damage: An attacker within Bluetooth range could potentially compromise the computer controlling critical robot functions, including motors, cameras, audio and other onboard systems.
- The Fix: G1 EDU owners should monitor Unitree’s security guidance for a confirmed fixed firmware release and restrict physical access to the robot while the remediation status remains unclear.
Your humanoid robot doesn’t need to be connected to the Internet to have a security problem.
Sometimes the attacker just needs to stand nearby.
Researchers have disclosed two separate vulnerabilities in the Unitree G1 EDU that can lead to root-level remote code execution.
One of the attack chains starts through Bluetooth Low Energy.
No Bluetooth pairing.
No credentials.
No password prompt.
Just proximity.
And eventually:
root.
Meet UniBLEed
Security researcher Olivier Laflamme disclosed the research under the name UniBLEed.
The vulnerabilities are tracked as:
CVE-2026-76639
and
CVE-2026-76640
The second vulnerability is the particularly nasty one.
It begins through the G1 EDU’s BLE interface and ultimately allows an attacker to execute commands as root on the robot’s Locomotion PC.
That’s not some secondary telemetry computer.
The Locomotion PC is responsible for important robot functions.
We’re talking about a machine sitting directly inside a physical device capable of moving around.
Bluetooth Is the Front Door
The BLE attack starts with a GATT characteristic identified as 0xFFE2.
The interface accepted writes with basic write permissions and did not require Bluetooth pairing for the initial interaction.
That creates a very different attack model from a traditional server.
You don’t necessarily need:
Internet access.
You don’t necessarily need:
an account.
You don’t necessarily need:
a stolen password.
You need to get close enough to communicate with the robot.
That’s it.
The Cloud Makes It Worse
The researchers found another problem in Unitree’s cloud API.
The robot uses cryptographic material during the BLE provisioning process.
Normally, the encryption should make extracting that material difficult.
But the researchers found that Unitree’s /device/bindExtData API could return the plaintext AES key associated with a supplied G1 serial number to an authenticated Unitree account.
The problem?
The API reportedly failed to verify that the account actually owned that robot.
So the attack chain becomes rather bizarre:
nearby robot
→ BLE interaction
→ cloud API
→ robot-specific key
→ authenticated BLE functions
→ Wi-Fi provisioning
→ memory corruption
→ root
That’s a lot of moving parts.
And that’s exactly why this isn’t a simple Bluetooth bug.
Then the Wi-Fi Configuration Explodes
After obtaining the required key material, the researcher could access protected BLE operations involved in Wi-Fi provisioning.
One stage abused an unsafe fallback in wpa_connect.sh.
Attacker-controlled input was inserted into an unquoted heredoc, allowing manipulation of the generated wpa_supplicant configuration.
At this point the robot can potentially be pushed toward an attacker-controlled wireless network.
But the researchers weren’t finished.
The Final Step: Root
The chain eventually reaches a memory-corruption vulnerability in the Bluetooth daemon.
The researchers describe a buffer overflow involving the Wi-Fi SSID handling that can corrupt an event-loop structure.
The corrupted control flow eventually reaches a system() call executing with UID 0.
Translation:
root.
The robot’s Bluetooth service crashes.
The attacker’s shell survives.
And the attacker has command execution on the Locomotion PC.
There Is Another RCE
CVE-2026-76639 is a separate root-RCE chain.
This one involves the robot’s chat_go AI service and a component called bashrunner.
The researchers found a path-traversal vulnerability in the AI chatbot’s knowledge-base upload mechanism.
That could be used to place a file in a location trusted by bashrunner.
The resulting chain can eventually reach code execution as root.
Yes.
The humanoid robot has an AI chatbot.
And the AI chatbot is part of one of the attack paths.
That sentence alone should make security teams uncomfortable.
This Isn’t Just About Making the Robot Say Something Weird
A compromised chatbot would already be annoying.
A compromised locomotion computer is something else.
The affected system handles functions associated with:
motors
cameras
audio
voice
and other robot capabilities.
Root access doesn’t automatically mean an attacker can instantly turn the robot into a Terminator.
That’s not what the research proves.
But it gives the attacker a privileged foothold on a system sitting directly next to physical hardware.
And that’s the important distinction.
In a normal server:
root = control over a computer.
In a robot:
root = potentially control over a computer connected to machinery.
The Researcher Tested Multiple G1 Robots
Laflamme says the vulnerabilities were reproduced on four G1 robots.
The propagation test was limited to two robots in the same room, so we shouldn’t turn that into a claim that every G1 on Earth can be remotely compromised.
The researcher also explicitly distinguishes the G1 EDU from other Unitree products and says that shared software components alone aren’t enough to declare every model vulnerable.
That’s an important limitation.
The affected scope currently centers on the G1 EDU firmware.
There Is a Patch Problem
Here’s the annoying part.
The vulnerability disclosure is public.
The CVEs are public.
The exploit research is public.
But an exact confirmed fixed firmware version has not been verified from Unitree’s available guidance at the time of reporting.
That’s not ideal.
A vulnerability disclosure without a clear remediation target leaves defenders in an awkward position.
You know what is broken.
You know how serious it can be.
You don’t necessarily know which firmware version definitively closes the hole.
This Isn’t the First Unitree Security Problem
The G1 isn’t new territory for security researchers.
NIST already documents earlier Unitree vulnerabilities affecting products including the G1, Go2, H1 and B2.
One previously documented issue allowed root command injection through malicious Wi-Fi configuration data delivered through BLE.
So the latest research isn’t happening in a vacuum.
It’s another demonstration that wireless interfaces and shared robotics software stacks deserve the same level of scrutiny as conventional network services.
The Physical Threat Model Is Different
This is where robotics security gets interesting.
A server can be hidden inside a data center.
A robot walks around.
That means the attacker model includes physical proximity.
A malicious device could potentially sit within radio range.
A visitor could be near the robot.
A compromised device in the same environment could attempt the attack.
You don’t need a global Internet scan.
You need:
distance.
That’s a surprisingly low barrier in a laboratory, warehouse, office or exhibition hall.
The Robot Doesn’t Need to Be “Hacked From the Internet”
That’s probably the biggest misconception this vulnerability kills.
People hear:
remote code execution
and assume:
Internet.
Not necessarily.
Remote can simply mean:
you aren’t physically controlling the machine yourself.
Bluetooth is remote.
Wi-Fi is remote.
A local network is remote.
And in this case, Bluetooth proximity is enough to start one of the chains.
Bugstoday Opinion
This is the kind of vulnerability that makes the phrase “smart device” sound increasingly optimistic.
The Unitree G1 EDU isn’t just a computer.
It’s a computer attached to a humanoid robot.
And researchers have now demonstrated two separate paths to root, including one starting from Bluetooth without pairing.
That’s a terrible combination of attack surface and physical capability.
The important thing is not to exaggerate it.
There is no evidence that hackers are currently walking around cities remotely hijacking G1 robots.
There is also no evidence that every Unitree robot is affected by these exact vulnerabilities.
But the technical demonstration is real.
And it shows something robotics manufacturers need to take very seriously:
once you put Linux, Bluetooth, cloud APIs, AI services and motors inside the same machine, a bug in any one of those layers can eventually become a physical-security problem.
Bugstoday verdict: Unitree G1 EDU just received the kind of security disclosure robotics manufacturers don’t want. Two separate root-RCE chains, one starting over unpaired Bluetooth, put a privileged shell inside a machine capable of moving in the real world. The robot doesn’t need an Internet connection to be interesting to an attacker. Sometimes the attacker just needs to be standing next to it.
