TL;DR
- 01What happened
On 20 September 2025, researchers Andreas Makris and Kevin Finisterre disclosed an exploit, dubbed UniPwn, for taking over Unitree’s humanoid (G1, H1) and quadruped (Go2, B2) robots through their Bluetooth setup entry point. Every unit used the same encryption key, and a handshake containing the string “unitree” was enough to pass authentication.
- 02Why nothing stopped it
Commands disguised as a Wi-Fi network name or password were then executed with root privileges. The researchers say a compromised robot could spread the attack automatically to nearby robots.
- 03The missing layer
Unitree said on 29 September that most fixes were complete, but until updates arrive, the same key opens every unit. What was missing was a layer that checks a connecting party against a key unique to each unit.
What happened
- Researchers
- Andreas Makris and Kevin Finisterre found and disclosed the flaws. With Víctor Mayoral-Vilches of Alias Robotics, they posted a paper on the G1’s security to arXiv (2025-09).
- Affected models
- The G1, H1, Go2 and B2, which share common firmware (NVD).
- Entry point
- The Bluetooth setup used to connect the robot to Wi-Fi.
- Why authentication passed
- The same encryption key and initialization vector (IV) were built into every unit (CVE-2025-60250), and any handshake containing the substring “unitree” was accepted (CVE-2025-60251).
- Root execution
- Commands slipped into strings sent as the Wi-Fi network name or password were executed as root when the Wi-Fi settings were applied (CVE-2025-35027, CVE-2025-60017).
- Spread to other units
- The researchers say a compromised robot could look for other Unitree robots within Bluetooth range and take them over automatically.
- Weak configuration encryption
- The paper says the encryption protecting settings also relied on a fixed scheme and predictable values.
- Outbound data
- The paper says the robot sent sensor and status data to two outside servers every 300 seconds without telling the operator.
Glossary
Bluetooth setup — The entry point used to connect a robot to Wi-Fi, by sending settings over Bluetooth from a nearby phone.
Root (root access) — The administrator level that can do anything on a device. Whoever holds it can control the device at will.
Firmware — The software that runs inside a device. Updates come from the vendor.
From the researchers’ disclosures, a takeover unfolds in this chain.
The stopping point is ②. Had the connecting party been checked against a per-unit key, a key extracted from another robot would not have worked.
Being nearby is enough.
No per-unit check.
Input is not validated.
The key is the same on all.
Timeline — disclosure and response
- The researchers contact Unitree.
- Makris publishes the keys on X. The researchers say Unitree stopped replying from this month (IEEE Spectrum).
- The paper is posted to arXiv.
- The researchers disclose UniPwn.
- The CVEs are published in the NVD.
- Unitree says on LinkedIn that most fixes are done.
The facts rely on the researchers’ paper (primary), the NVD CVE records and IEEE Spectrum’s reporting. This is a research demonstration, and the reports we consulted describe no real-world exploitation. This Brief does not assign blame to the manufacturer; its subject is the shared key and the missing input validation.
After disclosure
- Unitree: On 29 September it said on LinkedIn that it had begun addressing the concerns immediately, had completed most fixes, and would roll out updates soon (IEEE Spectrum). Whether updates had shipped was not confirmed as of IEEE Spectrum’s article (updated 2025-11).
- Researchers: Argued in the paper that defenses are needed as humanoid robots move into critical infrastructure.
Why it wasn’t stopped
The failure was not a lack of encryption. The key was the same on every unit, and nothing checked a connecting party against each unit’s own key.
The key was the same on every robot. Extract it from one, and it opened the entry point of every other unit too.
Proof here means accepting a connecting party only after checking it against a key unique to that unit. Detection means noticing a takeover or outbound data afterwards.
works on all
Researchers found and reported it, and Unitree worked on fixes. But fixes come after discovery, and units without the update still open with the same key. That distance is the gap between detection and proof, and it is structural.
The same structure appears in Universal Robots PolyScope (outside commands could be run through an industrial robot’s control screen).
How to counter this
Accept a connecting party only after checking it against a key or certificate unique to that unit. With a different key on each unit, a key taken from one robot does not open the others. Validate input arriving through entry points such as setup before using it. This layer sits in front of detection, not in place of it.
Industries and operations to watch
- IndustryManufacturing & core infrastructure
- Organizations that build robots or connected devices, and those that deploy them in factories and facilities.
- IndustryGovernment & public sector
- Organizations trialing robots for security or inspection (IEEE Spectrum noted UK police testing a Go2).
Do today’s controls close it?
| Control | This case | Why |
|---|---|---|
| Encrypting communications | Ineffective | The key was the same on every unit. |
| Handshake authentication | Ineffective | Anything containing “unitree” passed. |
| Network segmentation | Partial | Can restrict Wi-Fi traffic, but anyone nearby can reach the Bluetooth entry point. |
| Firmware updates | Partial | Unitree said most fixes were done, but no shipped update had been confirmed as of the 2025-11 report. |
- Give each unit its own key or certificate, and check connecting parties against it. Do not build the same secret into every unit.
- Validate input from setup and other entry points before using it. Do not pass strings received as a Wi-Fi name or password straight into execution.
- Disclose what devices send to outside servers, and let users turn it off. Let deploying organizations see where data goes and what it contains.
Three things to confirm for organizations that build or deploy robots and connected devices
- Have you confirmed with the vendor that strings arriving through device setup are never executed as-is?
- Do you know what your deployed devices send to outside servers?
- Do you have a procedure for receiving and installing firmware updates from the vendor?
Note: this attack requires being within Bluetooth range. We will revise this Brief if Unitree announces that updates have shipped.
Sources
- Research, primaryarXiv Mayoral-Vilches, Makris, Finisterre, “Cybersecurity AI: Humanoid Robots as Attack Vectors”
- Primary, CVENVD “CVE-2025-35027” (2025-09-26) — related: CVE-2025-60250, CVE-2025-60251, CVE-2025-60017
3 more (reporting, analysis)
- PressIEEE Spectrum “Exploit Allows for Takeover of Fleets of Unitree Robots”
- PressHelp Net Security “Humanoid robot found vulnerable to Bluetooth hack, data leaks to China”
- PressHackaday “Unitree Humanoid Robot Exploit Looks Like A Bad One”
References: “The last layer left in AI-era cyber defense”