Two agent sandboxes ship an unauthenticated shell endpoint on every interface

Take the Cua condition apart and neither line is wrong on its own. Authentication was enforced only when `CONTAINER_NAME` was set, which is how the server detects that it is running inside Cua's managed container; with the variable unset the server assumes local mode and skips authentication entirely ^[6]. Separately, the CLI default for `--host` was `0.0.0.0`, so local mode still listened on every interface ^[7]. The auth skip assumes the only client that can reach the port is the person at the keyboard, while the bind default assumes the network is friendly. Together, according to the CVE record as read in the dev.to writeup, an unauthenticated caller on TCP 8000 gets a `run_command` endpoint that executes shell commands, file endpoints for arbitrary read and write, and an interactive PTY ^[8].

AutoAgent's variant skips the conditional. Per the VulnCheck advisory cited in the same writeup, the sandbox TCP server binds `0.0.0.0` with no authentication and passes attacker-supplied bash to a shell ^[11], while the Docker environment runs the container as root and publishes the port on all interfaces ^[12]. The compose file also bind-mounts the host workspace directory, so root in the container reads and writes real files on the host ^[13].

That is where the word "sandbox" stops carrying weight. For the container to be the boundary the CVE records assume it is, you would need at least three things that are not in the shipped defaults: a non-root user or rootless mode, no writable host mount on the path the agent can reach, and a loopback bind instead of a published port. The writeup makes the same point from Docker's own documentation, which says rootless mode exists precisely because root-in-container is not a hard security boundary, and that a bind mount is the feature that opens a path back to the host ^[15].

Cua's fix is the part worth copying. Version 0.3.42 binds `127.0.0.1` in local mode, documented in commit 59cf25c0ec54 ^[9], and per the pull request discussion, going public now needs an explicit `CUA_ALLOW_INSECURE=1`; a cross-site origin check for `/cmd`, `/ws` and `/pty` was still in review when the author read the thread ^[10]. An environment variable with that name is hard to set by accident and harder to explain afterwards. AutoAgent's affected range runs through commit 16c12b052, and as of the September 5 records the advisory pointed at issue #96 with no confirmed fixed release ^[14].

The evidence has two limits worth naming. This is one writeup, by an author who says he maintains a small MCP security scanner and writes on agent security weekly ^[21], and its code blocks are reconstructions from the CVE record and fix commit rather than verbatim source, with the AutoAgent port number illustrative because the advisory pins none ^[18]. And the install path itself is not documented here: the writeup opens by asking who can reach a sandbox you start the way the README says ^[19], but what the sources actually show is the shipped CLI default and the compose defaults, not the text of either README.

The 9.8 score reflects how reachable the flaw is, and it makes no claim about an actual incident. Neither CVE was on CISA's KEV catalog when the author checked, and he found no confirmed in-the-wild exploitation in the advisories he read ^[17]. On CVSS 4.0 the same bugs come out at 9.3 ^[16], half a point lower than the 3.1 figure ^[20].