← Back to Feed CACHED · 2026-10-25 00:36:50 · CACHE_KEY CVE-2026-115995
CVE-2026-115995 · CWE-77 · Disclosed 2026-10-24

Unitree Go2 chat_go set_volume OS command injection via unsanitized Value parameter

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left the robot dog's volume knob wired straight into a shell, and now anyone on the WiFi can whisper `rm -rf` into its ear

CVE-2026-115995 is an OS command injection flaw in the set_volume() function of gpt_thread.py, part of the chat_go voice-assistant component ("BenBen") on the Unitree Go2 quadruped robot. Versions 1.1.11.0 through 1.1.11.4 are affected. The Value parameter passed to the volume-control function is concatenated unsanitized into an OS command — likely an os.system() or subprocess call against amixer or equivalent ALSA mixer utility — giving an attacker arbitrary command execution as the process owner. The fix in 1.1.11.5 adds input validation. The CVSS vector includes AV:N/AC:L/PR:N/UI:R/S:C — remote, low complexity, no auth, but *user interaction required*, with scope change reflecting potential pivot from the robot to the LAN.

The vendor-assigned CRITICAL 9.6 dramatically overstates the real-world risk for enterprise security teams. The Unitree Go2 is a consumer/research robot dog priced between $1,600 and $22,700 — not a server, not a network appliance, not identity infrastructure. Roughly 170,000 Go1/Go2 units exist worldwide, overwhelmingly in hobbyist, academic, and demo environments. The chat_go service runs on the robot's onboard NVIDIA Jetson and communicates via WebRTC over the local WiFi segment; it is not internet-facing by design. The UI:R requirement means the attack isn't fire-and-forget — someone must interact with the chat interface while the malicious payload is in flight. For an enterprise managing 10,000 hosts, the probability of having even *one* Go2 in the managed fleet is near zero, and even if present, its blast radius is limited to itself and whatever flat network segment it sits on. This is a genuine bug on an interesting platform, but calling it CRITICAL for enterprise patch prioritization is absurd.

"Robot dog command injection is real but irrelevant to 99.9% of enterprise fleets"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Attacker reaches the Go2's network segment

The chat_go service listens on the robot's local WiFi interface. The attacker must be on the same network segment — either the Go2's own hotspot network, the enterprise WiFi it's joined to, or reachable via the 4G/cloud relay if enabled. There is no evidence the set_volume endpoint is directly internet-routable. The CVSS AV:N reflects that the protocol is TCP/IP-based, not that it's internet-exposed.
Conditions required:
  • Network adjacency or access to the Go2's WiFi segment
  • Knowledge that a Go2 is present and its IP address
Where this breaks in practice:
  • The Go2 is typically on an isolated IoT or lab WiFi, not on the corporate backbone
  • Enterprise networks with proper segmentation make the robot unreachable from workstations
  • Most Go2 units are in homes, labs, or demo areas — not production data centers
Detection/coverage: Network scanners or asset inventory tools would flag the Go2 as an unmanaged Linux host. Nmap service fingerprinting can identify the WebRTC and DDS ports.
STEP 02

Trigger user interaction with chat_go

The CVSS vector specifies UI:R — the attack requires user interaction. The most plausible scenario is a social-engineering or man-in-the-middle attack where the attacker causes the voice assistant to process a malicious volume-control command. This could involve intercepting or injecting a WebRTC message while a legitimate user is interacting with the BenBen assistant via the Unitree mobile app. Without a user actively engaged with the chat interface, the vulnerable code path may not be reachable.
Conditions required:
  • A legitimate user must be actively interacting with the Go2's voice assistant
  • The attacker must inject or manipulate the Value parameter during this interaction
Where this breaks in practice:
  • Voice assistants on robot dogs are used intermittently, not continuously
  • The UI:R requirement means mass exploitation is impractical — each target needs individual social engineering
  • No public PoC or weaponized tooling exists to automate this
STEP 03

Inject OS command via set_volume Value parameter

The attacker supplies a crafted Value argument containing shell metacharacters (e.g., ; id, $(whoami), or backtick injection) to the set_volume() function. The function passes this unsanitized input to an OS command executor. The injected command runs with the privileges of the chat_go Python process, which on the Jetson likely runs as a non-root user but may have elevated permissions for audio hardware access.
Conditions required:
  • Successful delivery of malicious Value parameter through the chat_go interface
  • The Python process must have OS command execution privileges
Where this breaks in practice:
  • No public exploit code or PoC exists as of disclosure (2026-10-24)
  • The exact protocol and message format for reaching set_volume are undocumented — the Unitree SDK does not expose chat_go APIs
  • An attacker would need to reverse-engineer the WebRTC or internal API protocol
Detection/coverage: Process monitoring on the Jetson (if available) would catch unexpected child processes spawned by gpt_thread.py — look for bash, sh, nc, curl, wget child processes of the Python interpreter.
STEP 04

Establish persistence or pivot

With command execution on the Go2's Jetson, the attacker can exfiltrate data from the robot's cameras and microphones, use the robot as a pivot point onto the local network, or establish a reverse shell for persistent access. The Go2 runs a full Linux stack with network tools available. If the robot is on a flat enterprise WiFi segment, lateral movement to other hosts is theoretically possible, bounded by whatever network controls exist.
Conditions required:
  • Successful command injection from step 3
  • Outbound network connectivity from the robot for C2 or exfiltration
Where this breaks in practice:
  • Enterprise egress filtering would block reverse shells from an unmanaged IoT device
  • The robot's network position is typically on a guest/IoT VLAN, limiting lateral movement
  • EDR on enterprise hosts would detect scanning or exploitation attempts originating from the robot's IP
Detection/coverage: Network monitoring would flag unusual outbound connections from the robot's IP. IDS/IPS rules for reverse shell patterns would catch common post-exploitation tools.
03 · Compensating Control

1
MEDIUM 5.5→LOW 3.0
SEVERITY REDUCED
Isolate Go2 robots on a dedicated IoT VLAN with no route to production networks — Network segmentation is the single most effective control. Place all Go2 units on a purpose-built VLAN with ACLs blocking lateral movement to corporate subnets. This breaks the pivot-to-LAN step of the attack chain entirely. As this is a MEDIUM verdict, there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but this segmentation should be standard IoT hygiene regardless.
2
MEDIUM 5.5→IGNORE 0.0
SEVERITY REDUCED
Apply firmware update to 1.1.11.5 via Unitree OTA — The vendor fix is available and confirmed. Updating firmware eliminates the vulnerability entirely. Within the noisgate remediation SLA of 365 days for MEDIUM severity, schedule the update during a maintenance window. Given the low fleet count, this is likely a 15-minute task per robot.
3
MEDIUM 5.5→IGNORE 0.0
SEVERITY REDUCED
Disable the BenBen voice assistant if not operationally required — If the chat_go / voice-assistant functionality is not used, disable or stop the service on the Jetson. This eliminates the vulnerable code path entirely. SSH into the robot and stop the chat_go process or remove it from the startup sequence.
4
MEDIUM 5.5→LOW 3.5
SEVERITY REDUCED
Block outbound internet from the Go2 except required cloud endpoints — Egress filtering prevents a compromised robot from establishing C2 channels or exfiltrating data. Whitelist only Unitree's cloud endpoints and the OpenAI API endpoint required for voice processing. This degrades the post-exploitation impact even if injection succeeds.
What doesn't work
  • Enterprise EDR — the Go2 runs embedded Linux on an NVIDIA Jetson; no enterprise EDR agent (CrowdStrike, SentinelOne, Defender) supports this platform. You cannot detect exploitation via your standard endpoint stack.
  • WAF / reverse proxy — the chat_go service uses WebRTC and proprietary protocols, not HTTP. A web application firewall cannot inspect or filter this traffic.
  • Vulnerability scanners (Qualys, Tenable, Rapid7) — these tools have no plugins for Unitree Go2 firmware versioning. The robot will appear as an unmanaged Linux host at best, with no CVE-specific detection.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone reported. Not listed in CISA KEV. No known campaigns or threat actor usage as of 2026-10-25.
Proof-of-concept availabilityNo public PoC exists. Checked pocindex.io, GitHub, ExploitDB — no repositories or exploit code for CVE-2026-115995. The undocumented chat_go API raises the bar for exploit development.
EPSS scoreNot yet scored — CVE was disclosed 2026-10-24, EPSS data typically lags 24-72 hours. Given the niche product and UI:R requirement, expect a low EPSS probability (<5th percentile).
CISA KEV statusNot listed. No federal agency mandate to patch.
CVSS 3.1 vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — the UI:R and the niche deployment context are the key friction points that the score ignores.
Affected versionsUnitree Go2 firmware 1.1.11.0 through 1.1.11.4
Fixed version1.1.11.5 — firmware update via Unitree's official OTA channel
Installed base~170,000 Go1/Go2 units shipped globally (Unitree IPO filing). Overwhelmingly consumer/research. Enterprise IT fleet penetration is effectively zero for most organizations.
Internet exposureMinimal to none. The chat_go service is not internet-facing by design. No Shodan/Censys/GreyNoise data showing exposed Go2 chat_go endpoints. The robot communicates via local WiFi/WebRTC.
ReporterJasperXJY (VulDB User) — vendor confirmed via internal ticket #474

Sources.

  1. VulDB Advisory (CVE-2026-115995)
  2. Strix.ai CVE Analysis
  3. The Hacker Wire — Detailed Writeup
  4. Offseq Radar Threat Intelligence
  5. ThreatInt CVE Detail
  6. IEEE RAS — Unitree Fleet Exploit Analysis
  7. HackMD — Go2 Voice Interaction Architecture
  8. IEEE Spectrum — Unitree Robot Exploit
05 · The Call

Final Verdict
↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

  • UI:R is a hard gate. The CVSS vector requires user interaction — this is not a wormable, fire-and-forget exploit. Each target requires individual social engineering or MitM during an active voice-assistant session, which collapses mass-exploitation scenarios.
  • Near-zero enterprise fleet penetration. The Unitree Go2 is a $1,600–$22,700 robot dog. In a fleet of 10,000 managed enterprise hosts, the expected count of Go2 units is zero. Even organizations with robotics programs typically have 1–5 units in isolated lab environments, not on production networks.
  • No PoC, no exploitation, no KEV. Disclosed yesterday (2026-10-24) with no public exploit code, no active campaigns, and no CISA mandate. The chat_go API is undocumented, raising the reverse-engineering bar for would-be attackers.
  • Network position limits blast radius. The Go2 sits on a local WiFi segment — typically a guest/IoT VLAN in any properly segmented enterprise. Even full compromise of the robot yields access to one network-adjacent segment, not domain-wide or fleet-wide impact.
  • Role multiplier: no high-value role applies. The Go2 is not an identity provider, domain controller, hypervisor, CI/CD system, backup target, network edge appliance, SIEM, PKI component, or OT/SCADA controller. It is a peripheral sensor/mobility platform. Compromising it yields: (a) camera/mic access on the robot, (b) potential LAN pivot from one network segment. The blast radius is host-level to segment-level — never domain, fleet, or supply-chain scale. No high-value role represents ≥1% of the Go2 installed base in enterprise contexts, so no severity floor applies.

Why not higher?

A HIGH rating would be warranted if the Go2 were commonly deployed in enterprise production networks, if the vulnerability were exploitable without user interaction, or if there were active exploitation or public PoC code. None of these conditions hold. The product is a consumer robot dog with negligible enterprise penetration, and the UI:R requirement makes mass exploitation infeasible. No high-value deployment role floor is triggered because the Go2 is not infrastructure.

Why not lower?

A LOW rating would undercount the genuine risk for the small population that *does* operate Go2 robots in sensitive environments (defense research labs, law enforcement trials like the Nottinghamshire police, university robotics programs). On those devices, this IS unauthenticated remote command injection with camera/mic access and physical mobility — a legitimate espionage vector. The bug is real and the fix is straightforward, so it deserves tracking rather than dismissal.

06 · Verification

Crowdsourced verification payload.

Run this script on the Go2 robot itself via SSH (default user, or root if available). You need SSH access to the robot's Jetson compute board. Invoke: ssh unitree@<robot-ip> 'bash -s' < check_cve_2026_115995.sh. Requires read access to the filesystem to check firmware version files and the chat_go process.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_115995.sh
# Checks Unitree Go2 for CVE-2026-115995 (chat_go set_volume OS command injection)
# Run on the Go2 robot via SSH. Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

VULN_FIXED_VERSION="1.1.11.5"
RESULT="UNKNOWN"

# Function to compare semver-like version strings
version_gte() {
  # Returns 0 if $1 >= $2
  printf '%s\n%s' "$2" "$1" | sort -t. -k1,1n -k2,2n -k3,3n -k4,4n -C 2>/dev/null
}

# Attempt 1: Check firmware version from common Unitree version files
FW_VERSION=""
for vfile in /etc/unitree_version /opt/unitree/version /home/unitree/.config/unitree/version /etc/firmware_version; do
  if [ -f "$vfile" ]; then
    FW_VERSION=$(grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' "$vfile" | head -1)
    if [ -n "$FW_VERSION" ]; then
      echo "[INFO] Firmware version from $vfile: $FW_VERSION"
      break
    fi
  fi
done

# Attempt 2: Check if chat_go / gpt_thread.py exists and is running
CHAT_GO_RUNNING=false
if pgrep -f 'chat_go\|gpt_thread' >/dev/null 2>&1; then
  CHAT_GO_RUNNING=true
  echo "[INFO] chat_go process is RUNNING"
else
  echo "[INFO] chat_go process is NOT running"
fi

# Attempt 3: Look for the vulnerable set_volume pattern in gpt_thread.py
VULN_PATTERN_FOUND=false
for pyfile in $(find /opt /home /usr -name 'gpt_thread.py' 2>/dev/null); do
  echo "[INFO] Found gpt_thread.py at: $pyfile"
  # Look for os.system/subprocess with set_volume that lacks input sanitization
  if grep -qE 'def set_volume' "$pyfile" 2>/dev/null; then
    if grep -A5 'def set_volume' "$pyfile" | grep -qE 'os\.system|os\.popen|subprocess\.(call|run|Popen)' 2>/dev/null; then
      # Check if there's any sanitization (shlex.quote, re.sub, etc.)
      if ! grep -A10 'def set_volume' "$pyfile" | grep -qE 'shlex\.quote|re\.(sub|match)|int\(|float\(' 2>/dev/null; then
        VULN_PATTERN_FOUND=true
        echo "[WARN] Vulnerable set_volume pattern detected in $pyfile"
      else
        echo "[INFO] set_volume appears to have input sanitization in $pyfile"
      fi
    fi
  fi
done

# Determine result
if [ -n "$FW_VERSION" ]; then
  if version_gte "$FW_VERSION" "$VULN_FIXED_VERSION"; then
    RESULT="PATCHED"
    echo "[RESULT] PATCHED — firmware $FW_VERSION >= $VULN_FIXED_VERSION"
  else
    RESULT="VULNERABLE"
    echo "[RESULT] VULNERABLE — firmware $FW_VERSION < $VULN_FIXED_VERSION"
  fi
elif [ "$VULN_PATTERN_FOUND" = true ]; then
  RESULT="VULNERABLE"
  echo "[RESULT] VULNERABLE — vulnerable code pattern found in gpt_thread.py"
elif [ "$CHAT_GO_RUNNING" = false ]; then
  echo "[INFO] chat_go is not running; attack surface is not active"
  RESULT="UNKNOWN"
  echo "[RESULT] UNKNOWN — could not determine firmware version; chat_go not running"
else
  RESULT="UNKNOWN"
  echo "[RESULT] UNKNOWN — could not determine firmware version or inspect source"
fi

case "$RESULT" in
  VULNERABLE) exit 0 ;;
  PATCHED)    exit 1 ;;
  *)          exit 2 ;;
esac