bin4ry/unipwnBLE exploit framework for Unitree robots: command injection via hardcoded AES keys enables remote takeover, payload injection, and wormable propagation.
Author: Bin4ry aka Andreas Makris [[email protected]]
Co-Author: h0stile aka Kevin Finisterre
Contributor: legion1581 aka Konstantin Severov from theroboverse helped to fix the payload for the injection and proved it with a fully working PoC 🙂 thanks dude, this was a critical contribution, very much appreciated!
Date: September 20, 2025
CVE-2025-35027
CVE-2025-60017
CVE-2025-60250
CVE-2025-60251
The research from this repo is incorporated into a paper that presents a systematic security assessment of the Unitree G1. The reaserch impact is however NOT limited to just the G1, rather the entire Unitree product line from starting with the Go2 series. The code on newer Unitree bots appears to be a fork of the Go2 codebase, specifically making the Go1 lineage, and other pre-Go2 Unitree bots not vulnerable. All modern variants are however impacted at this time. Unitree has yet to release an advisory clarifying the exact impact across the product line.
Link to Paper: https://arxiv.org/abs/2509.14139
Title: Cybersecurity AI: Humanoid Robots as Attack Vectors
Authors: Víctor Mayoral-Vilches, Andreas Makris, Kevin Finisterre
@misc{mayoralvilches2025cybersecurityaihumanoidrobots,
title={Cybersecurity AI: Humanoid Robots as Attack Vectors},
author={Víctor Mayoral-Vilches and Andreas Makris and Kevin Finisterre},
year={2025},
eprint={2509.14139},
archivePrefix={arXiv},
primaryClass={cs.CR},
url={https://arxiv.org/abs/2509.14139},
}
During our security research on Unitree robotic platforms, we discovered a critical vulnerability in the Bluetooth Low Energy (BLE) Wi-Fi configuration interface. This vulnerability affects multiple Unitree robot models including Go2, G1, H1 and B2 series robots up to the latest firmware from today [20. September 2025].
🎯 This represents the first publicly disclosed exploit targeting humanoid robots!
The vulnerability combines multiple security issues: hardcoded cryptographic keys, trivial authentication bypass, and unsanitized command injection. What makes this particularly concerning is that it's completely wormable - infected robots can automatically compromise other robots in BLE range. This vulnerability allows the attacker to completely takeover the device.
We published the cryptographic keys in July Link to Tweet but Unitree did not care.
Let's dive into the technical details of how we discovered and exploited this vulnerability.
The first step was to identify the BLE services exposed by the robots. All affected Unitree models expose a custom BLE service for Wi-Fi configuration:
Service UUID: 0000ffe0-0000-1000-8000-00805f9b34fb
Write Characteristic: 0000ffe2-0000-1000-8000-00805f9b34fb
Notify Characteristic: 0000ffe1-0000-1000-8000-00805f9b34fb
Through reverse engineering, we discovered that the robot implements a receive manager that processes encrypted BLE packets. Here's what we found:
The receive manager first decrypts incoming packets using hardcoded AES parameters:
AES_KEY = "df98b715d5c6ed2b25817b6f2554124a"
AES_IV = "2841ae97419c2973296a0d4bdfe19a4f"
Mode: AES-CFB128
After decryption, the packets are processed based on instruction codes in a switch-case structure. Let's examine each instruction:
The handshake "authentication" is laughably simple:
Basically, the robot checks if the decrypted packet includes the string "unitree" as the handshake secret, then sets the valid_incoming_user flag to 1. That's the entire "authentication" mechanism!
This instruction checks if the user is "authenticated" (i.e., the flag is set), then reads the serial number file and returns it. This confirms we have access to the system.
This instruction initializes WiFi settings. Users can choose between AP mode (subcommand = 1) or STA mode (subcommand = 2):
This instruction stores the WiFi SSID. Here's our first injection point:
Similar to the SSID command, this stores the WiFi password. Another injection point:
This instruction sets the WiFi country code and, critically, triggers the WifiSettingThreadFunction:
When instruction 6 is executed, it starts the WiFi configuration thread, which leads us to the vulnerable functions.
The WiFi configuration thread calls either restart_wifi_ap or restart_wifi_sta depending on the mode:
Both restart_wifi_ap (hostapd_restart.sh) and restart_wifi_sta (wpa_supplicant_restart.sh) functions follow the same vulnerable pattern.
Here's the smoking gun (using restart_wifi_ap function as an example):
The function constructs this command:
sudo sh /unitree/module/network_manager/upper_bluetooth/hostapd_restart.sh "wifi_ssid wifi_pass"
This command is then passed directly to system() without any input validation or sanitization!
If we control either wifi_ssid or wifi_pass, we can inject our own commands. A simple payload like:
";$(reboot -f);#
Would be enough to reboot the robot. But we can do so much more...
Here's the complete attack sequence we need to execute:
";$(reboot -f);#If everything works, the robot should execute our injected command with root privileges.
What makes this vulnerability particularly dangerous is its wormable nature. With this method, we can:
An infected robot can simply scan for other Unitree robots in BLE range and automatically compromise them, creating a robot botnet that spreads without user intervention.
We developed a complete proof-of-concept exploit framework that demonstrates this vulnerability. The exploit includes:
Key components of our working exploit:
AES_KEY = bytes.fromhex("df98b715d5c6ed2b25817b6f2554124a")
AES_IV = bytes.fromhex("2841ae97419c2973296a0d4bdfe19a4f")
HANDSHAKE_CONTENT = "unitree"
def build_pwn(cmd):
return f'";$({cmd});#'
Unitree robots are already being deployed in critical real-world scenarios, making this vulnerability particularly concerning:
Law Enforcement: Nottinghamshire Police are currently trialing Unitree robots for armed response scenarios, including:
Military Operations: Unitree robots are being utilized by China's PLA for military applications, raising significant security implications for defense operations.
The implications of this vulnerability are quite serious:
0000ffe0-0000-1000-8000-00805f9b34fb0000ffe2-0000-1000-8000-00805f9b34fb0000ffe1-0000-1000-8000-00805f9b34fbdf98b715d5c6ed2b25817b6f2554124a (hardcoded, same across all devices)2841ae97419c2973296a0d4bdfe19a4f (hardcoded, same across all devices)Encrypted([0x52, length, instruction, data, checksum])
This research highlights several critical security principles:
We initially attempted responsible disclosure with Unitree regarding this vulnerability:
Given Unitree's lack of response and apparent disinterest in security issues, Andreas Makris has decided to discontinue private disclosure attempts with Unitree for future vulnerabilities. Any additional security issues discovered will be disclosed publicly without prior notification to the vendor.
This decision reflects Unitree's demonstrated unwillingness to engage constructively on security matters, particularly concerning given their deployment in law enforcement and military contexts.
(Initiated by Kevin Finisterre)
May 14, 2025 — Disclosure contact attempt made via LinkedIn and GitHub issue #126 despite multiple years of Unitree ignoring other report attempts from us, and our research peers.
Email titled “First, and last attempt to report another security issue in your flagship G1, and Go2, and other bots” sent to:
Tony Yang [email protected], [email protected], [email protected], Laikago [email protected], [email protected], [email protected], [email protected], Xing [email protected], XMath [email protected], [email protected], [email protected], [email protected], [email protected]
Unitree immediately suggested a potential bounty program in the future, but it was a premature discussion at this time.
May 28–29, 2025 — After two weeks discussing the general lack of Unitree seriousness regarding security [email protected] is created as a gesture of effort.
Email titled “Next steps... re: reporting critical vulnerability in Unitree G1” highlighted lack of disclosure practices, ignored Darknavy and prior reports, and suggested either an in-person demo with a debug build or a loaner bot (as Unitree sends to influencers). Both were refused, including an offer to meet at ICRA.
June 8, 2025 — Unitree responded: “A patch for Go1 ‘Zhexi' related, has already online at April” with link https://www.unitree.com/download/go1, adding “Github is only for repository running issues. So for cyber security, we suggest use now ways.” Replies dwindled.
— Pressed them on MIT Cheetah licensed code transparency; as opposed to using encryption routines, and controlled access to their linux subsystem instances to obfuscate borrowed code.
⚠️ Warning: This code is for educational and research purposes only. Do not use on devices you do not own.
This vulnerability is not an isolated incident. Previous research by ourselves has revealed concerning patterns in Unitree's security practices:
CVE-2025-2894: Researchers discovered a backdoor in the earlier Go1 series robots, which Unitree later claimed was "leftover code." However, as noted by us in the Go1 report, whether intentional backdoor or sloppy programming, both scenarios indicate a company that doesn't prioritize security.
Now, in the next generation of robots (Go2, G1, H1, B2), we see the same fundamental security failures: hardcoded keys, trivial authentication, and unsafe system calls. This suggests that Unitree has not learned from previous security issues and continues to ship products with critical vulnerabilities.
The pattern is clear:
For a company deploying robots in law enforcement and military contexts, this level of security negligence is unacceptable.
The combination of hardcoded cryptographic keys, trivial authentication bypass, and command injection creates a perfect storm for widespread exploitation. The wormable nature of this vulnerability makes it particularly dangerous in environments with multiple robots.
Given Unitree's track record of security issues and their deployment in critical law enforcement and military scenarios, immediate action is required to address these systemic security failures.
We've followed responsible disclosure practices and are working with Unitree to address these issues. This research is intended for educational and defensive purposes only.
⚖️ This research was conducted on legally owned equipment for educational and security research purposes. Any use of this information for malicious purposes is strictly prohibited and may violate applicable laws.
Remember: With great power comes great responsibility. Use this knowledge to build better, more secure systems!
If you find additional issues or improvements, please feel free to submit a pull request or open an issue.
These files are released with Creative Commons CC BY-NC-SA 4.0 licensing.
This license grants you specifc, but limited rights to use these files.
Attribution NonCommercial ShareAlike 4.0 International license
You are free to:
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
Attribution — You must give appropriate credit , provide a link to the license, and indicate if changes were made . You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NonCommercial — You may not use the material for commercial purposes.
ShareAlike — If you remix, transform, or build upon the material, you must distribute your contributions under the same license as the original.
No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Notices: Please read Creative Commons NonCommercial interpretation for more information on licensing.
This direclty means that you can NOT charge for access to these files, and you can not add them to your commercial vulnerability exploitation platform, or paywall them, because you explicity do not have permission to do so, you are in fact specifically prohibited from doing so without potential legal ramifications.
This research is shared for educational purposes. Please use responsibly.
Reply came June 26: “sorry for my late response. I’m not forget. Just need more time.”
Around this time Unitree posted a job listing for security staff. Job listing
July 18, 2025 — Email titled “Soooooo are we done here? Cuz I’m about done here….” sent due to silence, and lack of forward progress in negotiating disclosure boundaries.
July 20, 2025 — Unitree acknowledged that we have “G1 known vulnerabilities,” but claimed addressing our alleged findings with fixes "require full system iteration taking quarters or years,” and pointed to a forthcoming public security portal as a milestone.
July 25, 2025 — Unitree launched R1 marketing. After that, no further communications received.
Decision made to disclose publically, and let Unitree sort out on their own timeline. Further disclosure attempts for new finds will not be attempted.
September 2, 2025 - Unitree announces US$7B IPO valuation target in upcoming IPO for the 4th quarter of 2025.