Security researcher Olivier Laflamme spent roughly three months reverse-engineering the Unitree G1 humanoid robot and emerged with something every defender deploying humanoid platforms needs to internalize: a fully remote, cable-free path to root. He chained two separate vulnerabilities in the G1's software stack to achieve complete compromise, then demonstrated the scenario that should keep robotics program owners up at night — a compromised G1 using its own network access to attack other robots in physical proximity.
This is not a theoretical ICS whitepaper exercise. Humanoid robots are shipping into warehouses, research labs, hospitals, and manufacturing floors right now, typically connected to corporate wireless networks with little or no segmentation, running embedded Linux with vendor services exposed, and receiving minimal security scrutiny during procurement. The G1 research demonstrates that these devices are not just attack targets — they are mobile, physically capable lateral-movement platforms. A rooted robot in your facility is a rogue network device with legs, cameras, microphones, and the ability to pivot to its peers.
No CVE identifiers have been formally assigned to the flaws described in Laflamme's research at the time of this writing, and the vendor's patch posture remains a work in progress. That makes this a compensating-controls problem: you must detect, segment, and contain with what you have today.
Technical Analysis
Affected Platform
- Product: Unitree G1 humanoid robot
- Platform: Embedded Linux-based control stack with wireless connectivity (Wi-Fi/Bluetooth-class proximity interfaces), vendor cloud and remote-control services, and internal service daemons handling motion control and fleet communication
- Exposure window: Any G1 deployed on a reachable network segment, particularly flat corporate or lab networks where robots share broadcast domains with workstations, servers, or other robots
Attack Chain (Defender's View)
The research chained two distinct flaws — a pattern we see constantly in embedded and IoT engagements, where no single bug is catastrophic but the combination is total:
- Initial access flaw: A remotely reachable weakness in the G1's exposed services allowing unauthenticated or weakly authenticated interaction with the robot's software stack — no physical access, no cable, no pairing ceremony required.
- Privilege escalation flaw: A second vulnerability leveraged post-access to escalate to root on the embedded Linux operating system.
The critical defensive finding is the third stage: robot-to-robot propagation. A compromised G1 can use its local network position to attack neighboring robots. This converts a single-device vulnerability into a fleet-compromise scenario and gives the attacker a physically mobile pivot point inside your perimeter — one that bypasses your network access control by simply walking somewhere else.
Exploitation Status
- Public research with demonstrated proof-of-concept: Yes — full remote root compromise demonstrated and documented by the researcher.
- Confirmed in-the-wild exploitation: Not publicly confirmed as of this writing.
- CISA KEV: Not listed.
- Patch availability: Vendor remediation status remains incomplete; treat deployed G1 units as unpatched and apply compensating controls.
The window between "public PoC" and "commodity exploit" for embedded targets is historically short. Treat this as pre-exploitation exposure requiring action now.
Detection & Response
Humanoid robots rarely ship with EDR coverage, which means your telemetry has to come from two places: network-level monitoring (the robot's traffic is fully observable on your infrastructure) and host-level Linux telemetry where you have management access (auditd/syslog forwarding from the embedded OS, or a co-located sensor). The detections below target the behaviors inherent to this attack class: unexpected shells and child processes on the robot, scanning and lateral connection attempts between robots, and anomalous service exposure.
Sigma Rules
---
title: Suspicious Shell or Command Execution on Embedded Linux Robot Host
description: Detects interactive shells, downloaders, or post-exploitation tooling spawned on Linux-based robotic platforms such as the Unitree G1, consistent with remote root compromise via chained service vulnerabilities.
references:
- https://securityaffairs.com/198085/hacking/hack-one-robot-reach-the-next-unitree-g1-security-flaws.html
- https://attack.mitre.org/techniques/T1059/004/
author: Security Arsenal
status: experimental
date: 2026/02/14
id: 3f7a2c91-8b4d-4e61-a9c3-6d5f2e8b1a07
tags:
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_user:
User|contains:
- 'root'
selection_image:
Image|endswith:
- '/bash'
- '/sh'
- '/dash'
- '/curl'
- '/wget'
- '/nc'
- '/ncat'
- '/python'
- '/python3'
- '/nmap'
selection_parent:
ParentImage|endswith:
- '/sshd'
- '/dropbear'
- '/node'
- '/python3'
- '/java'
condition: selection_user and selection_image and selection_parent
falsepositives:
- Vendor maintenance scripts and firmware update routines executing shells as root
- Legitimate SSH administrative sessions from engineering workstations
level: high
---
title: Internal Network Scanning Originating from Robot Host
description: Detects use of network discovery and scanning utilities on embedded robot Linux hosts, a key indicator of the robot-to-robot lateral movement stage demonstrated in Unitree G1 research.
references:
- https://securityaffairs.com/198085/hacking/hack-one-robot-reach-the-next-unitree-g1-security-flaws.html
- https://attack.mitre.org/techniques/T1046/
author: Security Arsenal
status: experimental
date: 2026/02/14
id: 9c1e4b72-2d6a-4f38-b5e0-1a8c7d3f9e24
tags:
- attack.discovery
- attack.t1046
logsource:
category: process_creation
product: linux
detection:
selection:
CommandLine|contains:
- 'nmap'
- 'masscan'
- 'zmap'
- 'arp-scan'
- 'ping -c 1 192.168.'
- 'ping -c 1 10.'
- 'for ip in'
- '/dev/tcp/'
condition: selection
falsepositives:
- Fleet management or discovery protocols used by vendor software — baseline legitimate robot discovery traffic before tuning
level: medium
---
title: New Local User or Persistence Artifact Created on Embedded Linux Robot
description: Detects account creation and common persistence file modifications on robot Linux hosts, consistent with attacker entrenchment following root compromise of a Unitree G1-class platform.
references:
- https://securityaffairs.com/198085/hacking/hack-one-robot-reach-the-next-unitree-g1-security-flaws.html
- https://attack.mitre.org/techniques/T1136/001/
- https://attack.mitre.org/techniques/T1053/003/
author: Security Arsenal
status: experimental
date: 2026/02/14
id: 5d8f3a16-7c2b-4e94-a1d8-9b6e4f2c8a35
tags:
- attack.persistence
- attack.t1136.001
- attack.t1053.003
logsource:
category: process_creation
product: linux
detection:
selection_account:
Image|endswith:
- '/useradd'
- '/adduser'
- '/usermod'
- '/chpasswd'
selection_persistence:
CommandLine|contains:
- '/etc/rc.local'
- 'authorized_keys'
- '/etc/cron'
- 'crontab'
- 'systemctl enable'
condition: selection_account or selection_persistence
falsepositives:
- Vendor OTA update processes modifying startup configuration — correlate with known maintenance windows
level: high
KQL — Microsoft Sentinel (Syslog / CEF Ingestion)
Robot hosts will not have Defender onboarded, so hunt via Syslog forwarding from the embedded OS and network device telemetry. The first query hunts post-exploitation process execution on robot-class hosts; the second hunts the lateral movement stage using network flow data.
// Hunt 1: Suspicious root-level process execution on robot/embedded Linux hosts via Syslog
// Tune the host filter to your robot naming convention or dedicated syslog source
Syslog
| where TimeGenerated > ago(24h)
| where Computer has_any ("g1", "unitree", "robot") or SourceIP startswith "10.50." // adjust to robot VLAN
| where ProcessName in~ ("bash", "sh", "dash", "curl", "wget", "nc", "ncat", "nmap", "python3", "useradd", "crontab")
| where SyslogMessage has_any ("root", "uid=0")
| project TimeGenerated, Computer, SourceIP, ProcessName, SyslogMessage, SeverityLevel
| order by TimeGenerated desc
// Hunt 2: Robot-to-robot or robot-to-internal lateral connection attempts (network layer)
// Flags robot-source IPs initiating connections to multiple internal destinations on service ports
let RobotSubnet = "10.50.0.0/24"; // adjust to your robotics segment
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where ipv4_is_in_range(SourceIP, RobotSubnet)
| where ipv4_is_private(DestinationIP) and not(ipv4_is_in_range(DestinationIP, RobotSubnet))
| where DestinationPort in (22, 23, 445, 3389, 5900, 8080, 8443)
| summarize DistinctTargets = dcount(DestinationIP), Ports = make_set(DestinationPort), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP
| where DistinctTargets >= 3
| order by DistinctTargets desc
Velociraptor VQL — Endpoint Hunt on Robot Linux Hosts
Where you have SSH/management access to the G1's embedded OS or a co-managed gateway, deploy Velociraptor or run this logic interactively to hunt for post-compromise artifacts: unexpected listeners, root shells, and persistence artifacts.
-- Hunt for post-exploitation indicators on embedded Linux robot hosts:
-- unexpected listening services, root-owned shells, and recently modified persistence locations
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Username =~ 'root'
AND (
CommandLine =~ '(bash|/bin/sh|dash|nc |ncat|socat|python.*-m|curl|wget)'
OR Exe =~ '/tmp/|/var/tmp/|/dev/shm/'
)
-- Audit persistence surfaces modified within the last 14 days
SELECT FullPath, Mtime, Size, Mode
FROM glob(globs=[
'/etc/rc.local',
'/etc/cron.d/*',
'/root/.ssh/authorized_keys',
'/home/*/.ssh/authorized_keys',
'/etc/systemd/system/*.service'
])
WHERE Mtime > (now() - 1209600)
ORDER BY Mtime DESC
Bash Hardening & Verification Script
Run on the G1's embedded Linux OS (or your management gateway) to reduce attack surface, close unnecessary listeners, forward logs for detection, and establish an integrity baseline. Review before executing — embedded platforms vary, and disabling vendor services can impact functionality; test on one unit before fleet rollout.
#!/bin/bash
# Unitree G1-class embedded robot hardening & compromise-assessment script
# Run as root. Test on a single unit before fleet deployment.
set -u
LOG=/var/log/robot_hardening_$(date +%Y%m%d).log
exec > >(tee -a "$LOG") 2>&1
echo "=== [1] Firmware / software version inventory ==="
uname -a
cat /etc/os-release 2>/dev/null
# Record vendor firmware/app version for patch tracking against Unitree advisories
ls /unitree/ 2>/dev/null; dpkg -l 2>/dev/null | grep -i unitree
echo "=== [2] Enumerate listening services — close anything not operationally required ==="
ss -tulnp
echo "=== [3] Disable password-based and root SSH; require key auth from a jump host ==="
if [ -f /etc/ssh/sshd_config ]; then
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload sshd 2>/dev/null || service ssh reload 2>/dev/null
fi
echo "=== [4] Host firewall: deny inbound except approved management sources ==="
MGMT_NET="10.10.0.0/24" # <-- adjust to your robotics management network
if command -v iptables >/dev/null; then
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s "$MGMT_NET" -p tcp --dport 22 -j ACCEPT
echo "iptables policy applied: default-deny inbound, SSH from $MGMT_NET only"
fi
echo "=== [5] Enable auditd execve logging for detection content above ==="
if command -v auditctl >/dev/null; then
auditctl -a always,exit -F arch=b64 -S execve -k robot_exec
auditctl -w /root/.ssh/authorized_keys -p wa -k robot_persist
auditctl -w /etc/rc.local -p wa -k robot_persist
fi
echo "=== [6] Compromise assessment: hunt for the IOC classes in this post ==="
echo "--- Non-vendor processes running as root:"
ps -eo user,pid,comm,args | awk '$1=="root"' | grep -Ei 'bash|sh$|nc|ncat|socat|python|curl|wget|nmap' || echo "none"
echo "--- Executables in temp/world-writable dirs:"
find /tmp /var/tmp /dev/shm -type f -executable 2>/dev/null || echo "none"
echo "--- Recently modified persistence files (14d):"
find /etc/cron.d /etc/systemd/system /root/.ssh -mtime -14 -type f 2>/dev/null || echo "none"
echo "--- Unexpected users with UID 0:"
awk -F: '$3==0 {print $1}' /etc/passwd
echo "=== [7] Forward syslog to your SIEM (required for the KQL hunts) ==="
echo "*.* @your-siem-collector:514" > /etc/rsyslog.d/99-siem.conf
systemctl restart rsyslog 2>/dev/null || true
echo "=== Done. Review $LOG and reconcile findings against a known-good baseline. ==="
Remediation
1. Segment now — this is the single highest-value control. Place all humanoid robots on a dedicated, firewalled VLAN with:
- Client isolation / no east-west traffic between robots. The robot-to-robot attack path demonstrated in this research dies at this control. Robots have no legitimate need to initiate connections to one another on most deployments.
- Egress filtering: robots should reach only vendor update endpoints and your management infrastructure. Deny direct internet access otherwise.
- No routable path from the robot VLAN to production server, workstation, or OT segments except through inspected, logged gateways.
2. Track vendor remediation. Monitor Unitree's official channels and the researcher's disclosure for patch releases and advisory publication. Because no CVEs are formally assigned yet, anchor your vulnerability-management tracking to the vendor advisory and the research write-up, and demand a remediation timeline through your procurement channel. Do not assume silence equals safety.
3. Enforce firmware currency and verify. Establish a firmware baseline per unit, inventory all deployed G1s (serial, firmware version, network location, business owner), and build a patch SLA for robotics platforms identical to your server SLA. Embedded devices routinely fall outside patch-management tooling — close that gap explicitly.
4. Reduce exposed services. Apply the hardening script above (or your MDM/embedded-management equivalent): disable root SSH, key-only authentication from a jump host, default-deny host firewall rules, and removal of non-essential vendor daemons.
5. Get telemetry off the device. Forward syslog/auditd to your SIEM and deploy network detection on the robotics segment. A robot with no log forwarding is an unmonitored root shell waiting to happen. The Sigma and KQL content above is only useful if the data exists.
6. Add robotics to your IR plan and pen-test scope. Update incident response runbooks to include physical containment steps (power-down, RF isolation) for compromised robots. Include humanoid/embedded platforms in your next internal penetration test — the two-flux chaining pattern in this research is exactly what an assessor should attempt against your deployment.
7. Procurement governance. Require security documentation, SBOMs, vulnerability-disclosure policies, and patch commitments from robotics vendors before purchase. The G1 findings are representative of an immature product-security ecosystem; your contract language is leverage.
The strategic lesson matches what we've seen across IoT and OT for a decade: assume the device will be compromised, engineer the network so that compromise is contained, and ensure you can see it happen. Robots simply raise the physical stakes of getting that wrong.
Related Resources
Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.