Unauthenticated DDS remote code execution

1. Summary

The Unitree Go2’s onboard programming/actuator control plane exposes an Eclipse CycloneDDS topic, rt/api/programming_actuator/request, on DDS domain 0 with no authentication. Any device that can reach the robot’s internal DDS domain can publish a request whose api_id field selects a code-upload handler in actuator_manager.py, which writes attacker-supplied Python to disk and later runs it as root. The flaw is a missing-authentication-for-a-critical-function defect (CWE-306): the control plane routes messages solely by an untrusted api_id value with no caller identity or authorization check. Successful exploitation yields persistent root code execution on the robot after a physical controller hotkey is pressed.

2. Affected products & versions

Note: on the non-EDU V1.1.11 build the vulnerable DDS topics were reportedly suppressed; only the EDU build of V1.1.11 remained vulnerable [4].

3. The vulnerability in detail

The vulnerability lives in the Unitree Go2’s onboard programming/actuator control-plane service — principally actuator_manager.py, with a helper hotkey_manager.py — which is responsible for accepting user “programs” (Python scripts) and binding them to physical controller hotkeys so an operator can trigger custom robot behaviors [4]. This subsystem does not expose an ordinary authenticated API. Instead, it communicates over Eclipse CycloneDDS, the data-distribution middleware the robot uses for its internal message bus. Concretely, the service subscribes to the DDS topic rt/api/programming_actuator/request on DDS domain 0 [4].

The root cause is a missing-authentication-for-a-critical-function defect (CWE-306) compounded by unrestricted code injection. CycloneDDS in this deployment runs with its default configuration, which provides no built-in authentication or access control [4]. In DDS, any participant that can reach a given domain may join it and publish to its topics; there is no credential exchange by default. So any device with network reachability to domain 0 on the robot’s internal network — the robot sits at 192.168.123.161 on 192.168.123.0/24 — can become a publisher and send messages to the programming/actuator topic without any credentials [4]. On top of this transport-level exposure, actuator_manager.py dispatches an incoming request based solely on its api_id field. It never verifies that the sender is authorized to invoke the requested operation; the api_id alone chooses the handler [4]. This is the crux: an untrusted, unauthenticated value fully determines a privileged code path.

The specific privileged path is api_id=1002, which the service treats as a code-upload request [4]. The message body is JSON carrying chunk_index, total_chunk_num, the program’s Python source (pyCode), a program_uuid, and a bind_hotkey. Critically, actuator_manager.py validates only that these expected parameter fields exist — it performs no validation of the Python payload itself [4]. The handler then persists the supplied Python to disk under /unitree/etc/programming/, with the filename derived from program_uuid (stored via hotkey_manager.py), and records a controller-hotkey binding for the new program in /unitree/etc/programming/hotkey_list.txt [4]. At this point the attacker’s arbitrary code is resident on the device and armed to a hotkey.

The execution mechanism is the second half of the chain. The service monitors physical controller input via physical_remote_control_key_monitoring. When a bound hotkey combination is pressed — R1+Y, L1+Y, or L2+Y — the monitor resolves the binding and calls run_script, which launches the stored file with subprocess.Popen(['python3', script_path]) [4]. Because the actuator manager runs as root, the attacker’s Python executes with root privileges, e.g. a reverse shell yielding a full root shell and complete device control [4]. Persistence is inherent to the design: load_hotkey_list re-reads hotkey_list.txt on service start, so the malicious binding re-arms across reboots and the payload survives power cycles [4].

Preconditions and triggering: the attacker needs adjacent-network reachability to the robot’s DDS domain 0 (directly on 192.168.123.0/24, or via the external WiFi with appropriate routing / an explicit DDS peer configuration), plus CycloneDDS (0.10.2+) and unitree_sdk2_python tooling to construct the message. No authentication is required. The one non-network dependency is that a physical controller hotkey must be pressed to actually launch the stored script — this is why the CVSS vectors mark user interaction (UI:A / UI:R) [3][4]. Only the affected firmware versions expose the vulnerable topic.

The end-to-end exploitation chain is: (1) gain network adjacency and join DDS domain 0 (no credentials); (2) publish a crafted Request_ message to rt/api/programming_actuator/request with api_id=1002 and a JSON body containing chunk_index=1, total_chunk_num=1, the malicious Python, a program_uuid, and a bind_hotkey; (3) actuator_manager.py checks only field presence and writes the payload to /unitree/etc/programming/ plus the binding to hotkey_list.txt; (4) a physical hotkey (R1+Y/L1+Y/L2+Y) is pressed; (5) physical_remote_control_key_monitoring → run_script → subprocess.Popen(['python3', script_path]) executes the payload as root; (6) the binding reloads on every service start, providing reboot-surviving persistence [4].

In CWE terms, the assigned classification is CWE-306, Missing Authentication for Critical Function: a security-relevant operation (uploading and later executing code) is reachable with no proof of identity or authority. The researcher writeup additionally frames the full chain as touching CWE-287 (Improper Authentication), CWE-94 (code injection — the service generates/executes code from attacker-controlled input), and CWE-434 (unrestricted upload of a dangerous file type — arbitrary Python written to a directory it will later execute) [4].

Proof-of-concept status: a functional public PoC is published in the Boschko Security writeup — a Python script that builds the Request_ DDS message with a reverse-shell payload and sends it to the topic, requiring CycloneDDS 0.10.2+ and unitree_sdk2_python [4]. (Note: the separately named utility modify_db_v1.1.11_rce.py referenced in the writeup belongs to the sibling CVE-2026-27510, not this DDS vector [4].)

4. Discovery & timeline

The vulnerability was discovered by Olivier Laflamme (@olivier_boschko, Boschko Security) and Ruikai Peng (@ruikai, Pwn0 founder), via coordinated responsible disclosure with Unitree’s security team [4]. It was found on Oct 26 2025 against firmware V1.1.7 [4]. Coordinated disclosure began around Oct 29–30 2025; during this window V1.1.11 testing showed the DDS topics suppressed on the standard build but the EDU build still vulnerable [4]. Unitree’s security team validated and reproduced the issue across V1.1.7–V1.1.11 EDU between Nov 10 and Nov 18 2025 [4]. Public disclosure occurred Feb 27 2026, with NVD/CVE.org publication around Feb 26 2026 [4][2]. The fix shipped in standard firmware V1.1.13 per the researcher writeup and SentinelOne; EDU units are considered unlikely to be patched [4][7].

5. Technical reference

• CVE: CVE-2026-27509 (sibling: CVE-2026-27510, same root-execution sink reached via Android-app SQLite pyCode tampering) [2][4][8].
• CWE: CWE-306 (Missing Authentication for Critical Function) — assigned per NVD/VulnCheck. Researcher-characterized additional weaknesses: CWE-287, CWE-94, CWE-434 [3][4].
• CVSS v4.0: 8.5 HIGH — CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (VulnCheck) [3]. Key metrics: AV:A (adjacent — attacker must reach the robot’s DDS network, not the open Internet), PR:N (no privileges), UI:A (a physical hotkey press is required to trigger execution), and VC:H/VI:H/VA:H (high confidentiality/integrity/availability impact from root control).
• CVSS v3.1: 8.0 HIGH — CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H (VulnCheck) [2]. UI:R again reflects the required controller keypress; scope unchanged (S:U).
• Code / component refs: actuator_manager.py, hotkey_manager.py; DDS topic rt/api/programming_actuator/request (domain 0); on-disk artifacts under /unitree/etc/programming/ including hotkey_list.txt. No public source commit/patch hash was located [4].

6. Consequence & CFSE path analysis

Real-world consequence: an attacker who can reach the robot’s internal DDS network can plant persistent code that runs as root on a walking, sensor-laden robot. That root foothold does two independently serious things. First, it reaches the actuator/motion control path, so the attacker can drive physical actuator and motion commands — a robot that moves near people can physically endanger them. Second, that same root access grants live access to the robot’s onboard camera, LIDAR, navigation, and spatial-sensor state, enabling surveillance and data exfiltration. Both consequences are enabled by the single defect and both survive reboots.

Why the CFSE Path Score differs from the CVSS baseline: CVSS scores the technical exploit (adjacent-network, unauthenticated, root code execution gated on a physical keypress) and lands at v4.0 8.5 HIGH / v3.1 8.0 HIGH. CFSE decomposes the same CVE into two co-dominant consequence paths and reasons about downstream, real-world impact that CVSS’s impact metrics do not fully capture — cyber-physical safety, perception privacy, fleet-wide reuse, and recovery burden.

CFSE consequence bands and verdict:

• verdict: CRITICAL.
• The entry decomposes CVE-2026-27509 into two co-dominant consequence paths, both banded CRITICAL.
• DEVICE_CONTROL_SAFETY path (safety family): an unauthenticated DDS publish on domain 0 carrying api_id=1002 arbitrary Python runs as root via the actuator_manager path, reaching actuator/motion commands that can physically endanger nearby people (PH=CRITICAL, AT=HIGH, cross-domain bridge CH=4, persistence OR=4).
• PERCEPTION_PRIVACY path (privacy family): the same root execution grants live access to onboard camera, LIDAR, navigation, and spatial-sensor state for surveillance/exfiltration (DP=CRITICAL), also banded CRITICAL.
• Both paths treat exposure as reachability-bound (EX=2, RE=2, network/DDS-adjacent) with a reproducible unauthenticated exploit workflow (EC=3), and note a vendor patch is available (LS=PATCH_AVAILABLE).
• Overall path_verdict: CRITICAL, direction UNDER relative to the published v4.0 8.5 HIGH / v3.1 8.0 HIGH baselines, reflecting the added cyber-physical safety and perception-privacy consequence, fleet-wide reuse, and manual-cleanup recovery burden.

7. Remediation & mitigations

• Update standard firmware to V1.1.13 or later, which addresses this vector per the researcher writeup and SentinelOne [4][7]. Note the available sources do not definitively state whether V1.1.13 adds DDS authentication or removes/suppresses the programming_actuator topic (as the non-EDU V1.1.11 build reportedly did) [4].
• For EDU units, which are unlikely to receive a vendor patch, isolate the device: they should not share a network segment with untrusted devices [4].
• Where the DDS domain must remain reachable, enable DDS authentication/access control — CycloneDDS ships here with a default no-auth configuration — and network-segment/firewall the robot’s internal DDS domain (192.168.123.0/24) so untrusted devices cannot join domain 0 [4].
• Understand the residual risk: patching this DDS vector does not close the sibling CVE-2026-27510, which reaches the same root-execution sink in actuator_manager via Android-app SQLite pyCode tampering. Remediation should account for both paths to the shared sink [4][8].
• Detection specific to this bug: unexpected files appearing under /unitree/etc/programming/ and unexpected entries in /unitree/etc/programming/hotkey_list.txt, and unexpected python3 subprocesses spawned by the actuator manager, are direct indicators of this exploit having been staged [4].

8. Sources

• [1] CVE Record: CVE-2026-27509 — CVE.org (MITRE) — https://www.cve.org/CVERecord?id=CVE-2026-27509 — authoritative CNA-issued canonical record and references (not individually fetched). Credibility: primary-advisory.
• [2] NVD - CVE-2026-27509 — NVD (NIST) — https://nvd.nist.gov/vuln/detail/CVE-2026-27509 — CVSS v4.0 8.5 / v3.1 8.0 enrichment, affected version ranges, reference list. Credibility: primary-advisory.
• [3] Unitree Go2 Missing DDS Authentication Enables Adjacent RCE (VulnCheck Advisory) — VulnCheck (CNA) — https://www.vulncheck.com/advisories/unitree-go2-missing-dds-authentication-enables-adjacent-rce — originating CNA advisory: CVSS v4.0 vector, affected firmware, topic/mechanism, CWE-306, researcher credit. Credibility: primary-advisory.
• [4] From DDS Packets to Robot Shells: Two RCEs in Unitree Robots (CVE-2026-27509 & CVE-2026-27510) — Boschko Security (Olivier Laflamme, Ruikai Peng) — https://boschko.ca/unitree-go2-rce/ — the original researcher writeup; deep mechanics (DDS domain 0 join, api_id=1002 routing, /unitree/etc/programming/, hotkey triggers, reboot persistence), timeline, and public PoC. Credibility: researcher-primary.
• [5] GitHub Advisory Database - GHSA-hcv4-2wj7-9p5g (CVE-2026-27509) — GitHub Advisory Database — https://github.com/advisories/GHSA-hcv4-2wj7-9p5g — advisory mirror with affected version enumeration (not individually fetched). Credibility: primary-advisory.
• [6] CVE-2026-27509 (Tenable) — Tenable — https://www.tenable.com/cve/CVE-2026-27509 — independent database summary corroborating description/severity/versions (not individually fetched). Credibility: reputable-press.
• [7] CVE-2026-27509: Unitree Go2 Firmware RCE Vulnerability — SentinelOne — https://www.sentinelone.com/vulnerability-database/cve-2026-27509/ — confirms the actuator_manager.py mechanism, patch in V1.1.13, CVSS 8.5 HIGH. Credibility: reputable-press.
• [8] Unitree Go2 Mobile Program Tampering Enables Root RCE (VulnCheck Advisory, CVE-2026-27510) — VulnCheck (CNA) — https://www.vulncheck.com/advisories/unitree-go2-mobile-program-tampering-enables-root-rce — sibling CVE reaching the same root sink via Android SQLite tampering; context on the shared code path. Credibility: primary-advisory.