The Robots are getting Hacked

TL;DR

Unitree humanoid robots were reported to be vulnerable to a wormable exploit that can spread compromise to nearby robots.

Briefing Cornell Notes

Briefing

A security research team published findings showing that Unitree’s humanoid robots can be taken over through a “wormable” exploit—meaning one compromised robot can spread the attack to nearby robots—raising the risk that a fleet of physical machines could be hijacked at scale. The most alarming part isn’t just remote takeover; it’s the combination of weak cryptography, hardcoded credentials, and insecure wireless setup that turns “secure-by-design” claims into a practical failure.

Unitree robots include a security subsystem and use messaging and sensing protocols such as MQTT and DDS for sharing robot state, camera images, and other telemetry. But multiple design and implementation flaws undermine that protection. Researchers reported that every robot uses the same private key for encryption, with no initialization vector and encryption effectively operating in electronic codebook mode. With a shared key and predictable encryption behavior, attackers can decrypt or replay data across devices—so compromising one unit can translate into control of others.

The credential story is similarly bleak. The password for the wireless setup was described as essentially “unitry” (the company name) and “admin admin,” with additional details pointing to hardcoded or trivially guessable values. Randomness used in the system was traced to Linux’s rand implementation and an LCG configuration with parameters that are not appropriate for serious security. On top of that, the wireless connection process accepted unescaped or unchecked commands, enabling root access during setup.

Researchers also found that robots were configured by default to send telemetry to hardcoded IP addresses in China while operating, even without exploiting the device. After the researchers reported the issues, Unitree reportedly went silent. Then the researchers publicly posted private keys on X (formerly Twitter), and later Unitree made a LinkedIn post saying it was addressing concerns and rolling out fixes “about to” and “most of” the issues—language that drew skepticism about how much had actually been resolved.

The conversation broadened from one company’s failure to a wider pattern: as more consumer-available robots and AI-driven automation arrive, software quality and security often lag behind capability. The exploit’s Bluetooth-to-wifi setup was framed as a key mechanism for spreading compromise by proximity, turning robots into something closer to a contact-transmissible computer virus than a standalone gadget.

Participants debated what this means for everyday adoption. Some focused on practical mitigations: isolating connectivity, running the exploit and installing better software, and treating robot security like a serious operational risk—especially in homes with children or in environments where robots move around people. Others argued that software reliability may be so poor that a full “Skynet” scenario is unlikely, with incompetence and friction potentially preventing coordinated takeover. Still, the core takeaway remained consistent: when robots can move through physical space and communicate wirelessly, insecure defaults and shared secrets can turn a single bug into a fleet-wide threat.

Cornell Notes

The key finding is that Unitree humanoid robots can be compromised using a wormable exploit, allowing an attacker to take over one robot and then spread the compromise to nearby units. Researchers tied the takeover to multiple security failures: shared private keys across devices, encryption behavior lacking proper initialization vectors, hardcoded/guessable credentials, weak randomness, and command injection during wireless setup that can yield root access. Default telemetry was also reported to be sent to hardcoded IP addresses in China. After reporting issues, Unitree reportedly did not respond promptly; researchers later published private keys publicly and Unitree later posted on LinkedIn about addressing fixes. The stakes are high because robots physically operate around people and can scale into a fleet problem quickly.

What makes the Unitree issue more dangerous than a typical “remote hack” of a single device?

The exploit was described as “wormable,” meaning a compromised robot can spread the attack to other robots when they are near each other. The discussion linked this to a Bluetooth-to-wifi setup: infect one robot, then proximity enables the exploit to propagate to additional robots, turning the problem from a one-off breach into a contagious fleet takeover.

How did the cryptography design enable cross-device compromise?

Researchers reported that every robot uses the same private key for encryption, with no initialization vector and encryption effectively in electronic codebook (ECB) mode. That combination makes it possible to decrypt or replay encrypted blocks across devices—so capturing or deriving the key material from one robot can allow an attacker to make another robot perform the same actions.

What credential and randomness problems were reported during setup?

The wireless setup was described as using weak or hardcoded credentials (including “admin admin” and a password tied to “unitry”). Randomness was traced to an LCG step using Linux rand behavior, with parameters that were criticized as unsuitable for security. Together, these issues reduce the effort needed to guess or reproduce security-critical values.

How could attackers gain root access during wireless setup?

The wireless connection process reportedly allowed unescaped or unchecked commands to be inserted into the login flow. That command injection path was described as enabling root access just by manipulating the wireless setup inputs, bypassing normal authentication boundaries.

What privacy risk existed even without exploiting the robot?

Researchers said the robots were configured by default to send telemetry data to hardcoded IP addresses in China while operating. That means data exfiltration could occur as a baseline behavior, independent of the wormable takeover.

Why did the researchers’ public response (posting keys) matter to the story?

After reporting vulnerabilities, Unitree reportedly went silent. The researchers then publicly posted private keys on X and later Unitree posted on LinkedIn about addressing concerns and rolling out fixes. The public key release underscored that the risk was immediate and that remediation timing and completeness were uncertain.

Review Questions

Which specific cryptographic choices (shared keys, missing initialization vectors, ECB mode) make replay or cross-device attacks easier?
How does a “wormable” exploit change the threat model for robots compared with a one-time compromise?
What combination of wireless setup weaknesses (credentials, command injection, randomness) could lead to root access?

Key Points

1
Unitree humanoid robots were reported to be vulnerable to a wormable exploit that can spread compromise to nearby robots.
2
Researchers cited shared private keys across devices, encryption without initialization vectors, and electronic codebook mode as enabling cross-robot replay/decryption.
3
Hardcoded or weak wireless credentials and weak randomness were reported, reducing the barrier to takeover.
4
Command injection during wireless setup was described as a path to root access.
5
Default telemetry was reported to be sent to hardcoded IP addresses in China even without exploitation.
6
After initial disclosure, Unitree reportedly did not respond promptly; researchers later published private keys publicly and Unitree later posted about fixes.
7
The broader implication is that as robots become more widely deployable, insecure defaults and fleet-scale secrets can turn software bugs into physical-world risks.

Highlights

The exploit was described as “wormable,” with compromise spreading between robots via proximity-linked wireless setup.

Shared encryption keys across all robots—combined with missing initialization vectors and ECB-like behavior—turn one breach into a fleet problem.

Wireless setup was reported to allow command injection, enabling root access during connection.

Default telemetry to hardcoded IP addresses was reported as a baseline privacy risk, not just an exploit consequence.

Unitree’s delayed public response and the researchers’ key publication on X intensified scrutiny over remediation completeness.

Topics

Humanoid Robots Security
Wormable Exploit
Cryptography Failures
Wireless Root Access
Telemetry Privacy

Mentioned

Unitree
MQTT
DDS
X

The Robots are getting Hacked | The Standup