Unauthenticated Root RCE in AutoAgent's Sandbox TCP Server

Executive Summary

A critical unauthenticated remote code execution vulnerability (CVE-2026-86124) has been disclosed in AutoAgent, the HKUDS open-source AI agent framework. The flaw sits in AutoAgent's sandbox TCP command server, which binds to 0.0.0.0 and executes any command it receives as root, without any form of authentication or authorization check.

CVSS Score: 9.8 (Critical) under CVSS 3.1; a CVSS 4.0 score of 9.3 has also been reported by other trackers.

Any host that can reach the exposed TCP port can send arbitrary bash commands and have them executed inside the AutoAgent sandbox container as root — including read/write access to any bind-mounted host workspace directories.

Vulnerability Overview

Technical Details

AutoAgent's sandbox environment spins up a Docker container to isolate agent-executed code, and communicates with that container through a lightweight TCP command server. Two design decisions in that server compound into full root RCE:

1. tcp_server.py — the TCP listener binds to 0.0.0.0 (all network interfaces) and accepts inbound connections with no authentication or authorization check whatsoever. Any client that can open a TCP connection to the port can submit shell commands for execution.
2. docker_env.py — the sandbox container itself is launched with docker run --user root, and the command port is published with -p, exposing it on 0.0.0.0 at the host level as well.

Together, these mean a remote, unauthenticated attacker who can reach the published port can execute arbitrary bash commands as root inside the container — and, because AutoAgent sandboxes typically bind-mount a host workspace directory in for agent file access, that access can extend to files outside the container itself.

1. Attacker scans for hosts exposing the AutoAgent TCP command port
2. Attacker opens a raw TCP connection — no credentials, tokens, or handshake required
3. Attacker sends a bash command payload
4. Command server executes the payload as root inside the sandbox container
5. Attacker pivots via bind-mounted host directories or lateral network access

Impact of Successful Exploitation

Immediate Remediation

No official patched release was confirmed at the time of publication. Until a fix ships, mitigate at the deployment layer:

Step 1: Take the Port Off the Public Network

# Never publish the sandbox command port on 0.0.0.0.
# Bind it to localhost only, or drop the -p flag entirely if the
# container doesn't need external reachability.
docker run --rm -p 127.0.0.1:<port>:<port> autoagent-sandbox

Step 2: Restrict at the Firewall / Security Group

# Block the AutoAgent TCP command port from any interface other than loopback
sudo ufw deny in on eth0 to any port <port> proto tcp

Step 3: Stop Running the Sandbox as Root

Remove --user root from the docker run invocation in docker_env.py (or the equivalent deployment config) and run the sandbox under a non-privileged UID with the minimum filesystem permissions the agent actually needs.

Step 4: Front the Command Server With Authentication

If the TCP server must be reachable beyond localhost, put it behind mutual TLS or a token-based auth proxy — do not rely on network segmentation alone.

If Immediate Mitigation Isn't Possible

1. Do not expose AutoAgent sandboxes to any untrusted network, including shared internal networks.
2. Audit existing deployments for the port being reachable from outside the host.
3. Monitor for unexpected inbound TCP connections to the sandbox port and unexpected process spawns inside the container.

Detection Indicators

References

• VulnCheck — AutoAgent Unauthenticated Remote Code Execution via the Sandbox TCP Command Server
• NIST NVD — CVE-2026-86124
• OffSeq Threat Radar — CVE-2026-86124

Related Reading

• Cua Computer-Server Unauthenticated RCE (CVE-2026-86121)
• WordPress Plugin Vulnerability (CVSS 10.0) Under Active