CVE-2026-86124: AutoAgent ships a root shell open to the entire network. I read the advisory twice because I thought I misread the CVSS. I didn't. 9.8 (9.3 under CVSSv4). AV:N, PR:N, UI:N. No auth, no user click, no local access needed. Here's the chain: AutoAgent (HKUDS's agent framework) runs a TCP command server for its internal control channel. That server binds to 0.0.0.0, all interfaces, not just localhost. It accepts raw bash commands and executes them as root inside the container. The container has bind-mounted host workspace directories. So: anyone who can reach that port sends a command, gets root, and lands on a path that touches your host filesystem. No exploit chain, no memory corruption, no clever payload. Just an open door someone forgot to lock. This is the pattern I keep seeing in agent frameworks. People design the "agent brain" carefully: guardrails on the LLM, sandboxing for tool calls, prompt filtering. Then they wire up an internal RPC/control channel for orchestration and treat it as trusted-by-default because "it's just internal." Internal only stays internal if the bind address says so. Building agent infra? Two checks that would've caught this before it shipped: BEFORE (dangerous): server.listen(port, "0.0.0.0") on any control/RPC channel, no auth check. AFTER (safe): bind to 127.0.0.1 or a unix socket unless you have a real reason not to, require a token/mTLS on the channel, and never run the listener process as root even in a container. If you're running AutoAgent in a container right now: is that port actually firewalled off, or just "probably fine because it's in Docker"? Docker networking is not a security boundary by default. #AISecurity #CVE #AgentSecurity
Post summary
The tweet announces a new high‑severity vulnerability (CVE‑2026‑86124) in AutoAgent that allows unauthenticated remote root access via an open TCP control channel, detailing its CVSS, vectors, and technical exploitation path.
