Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2026-86124

  • Cua and AutoAgent take 9.8s for unauthenticated command execution, and Cua’s named fix version changed a bind default, not the authentication

    Cua and AutoAgent take 9.8s for unauthenticated command execution, and Cua’s named fix version changed a bind default, not the authentication

    Two CVEs published minutes into Friday morning describe the same architecture — a sandbox whose job is to run commands for an AI agent, listening on every interface with the authentication check disabled — and neither product has a fix that closes it.

    What happened

    Two records landed in the National Vulnerability Database at 10:16 a.m. UTC on Friday, September 5, 2026, less than half a second apart, from the same CNA and crediting the same researcher. Both carry a CVSS v3.1 base score of 9.8 and a CVSS v4.0 base score of 9.3, both scored by VulnCheck. Both are filed under CWE-306, missing authentication for a critical function. Both have a vulnStatus of Received, meaning NVD has not yet enriched them.

    CVE-2026-86121 covers Cua’s computer-server. The record reads, in full: “Cua computer-server versions before 0.3.42 skip authentication when the CONTAINER_NAME environment variable is unset and bind to all interfaces by default, allowing unauthenticated attackers to execute arbitrary commands.” VulnCheck’s advisory adds that the reachable surface is TCP port 8000, and that an attacker who reaches it gets command execution, arbitrary file read and write, and an interactive PTY shell. Cua is a computer-use agent platform whose README describes building “agents that see screens, click buttons, and complete tasks autonomously”; computer-server is the daemon that carries those actions out inside the VM or container. The repository has 22,200 stars.

    CVE-2026-86124 covers AutoAgent, an LLM agent framework from HKUDS with 9,700 stars and 1,400 forks, described by its authors as a “Fully-Automated and highly Self-Developing framework that enables users to create and deploy LLM agents through Natural Language Alone.” That record reads: “AutoAgent contains an unauthenticated remote code execution vulnerability in the TCP server that binds to all interfaces and executes attacker-supplied commands as root.” VulnCheck’s advisory names two files — autoagent/environment/tcp_server.py, which binds 0.0.0.0 with no authentication check, and autoagent/environment/docker_env.py, which runs the container as root and publishes the port to 0.0.0.0 on the host. The container bind-mounts the user’s workspace directory, so host files are in reach.

    Both were reported in public on June 13, 2026, by the same person: GitHub user geo-chen, credited in both VulnCheck advisories as George Chen. The CVEs published 84 days later. Both upstream issues — trycua/cua#1892 and HKUDS/AutoAgent#96 — were still open when this story was checked on the morning of September 5. The AutoAgent issue states the case plainly: “There is no token, signature, or origin check; the protocol is ‘connect, send command, receive output.’”

    What the fix version fixes

    AutoAgent’s record names no fixed version at all. Its affected range is expressed as a git commit — everything through 16c12b052ef2330a198063c62a07a7f9723031e3 — and VulnCheck’s advisory carries no remediation.

    Cua’s record does name one: 0.3.42, published to PyPI on June 24, 2026, eleven days after the report. VulnCheck’s advisory describes the fix as a bind-address change, and the commit it lists among its references, 59cf25c0ec54, carries the message “chore(python): scope lint baseline (#1846).” The change inside it that matters flips the command-line default from 0.0.0.0 to 127.0.0.1, and rewrites the help string to read “Host to bind the server to (default: 127.0.0.1; use 0.0.0.0 for external access).”

    That addresses the second clause of the CVE description. It does not address the first. Read on the project’s main branch on the morning of September 5 — twice, through two different URL forms, because a claim about what code does not contain deserves more than one look — AuthenticationManager.auth() in computer_server/main.py still carries this:

    # If no CONTAINER_NAME is set, always allow access (local development)

    followed by a return True. The same file’s own entry point still calls uvicorn.run(app, host="0.0.0.0", port=8000); only the CLI wrapper got the new default. Two releases have shipped since the named fix — 0.3.43 and 0.3.45, both on August 28, 2026 — and the current release is 0.3.45.

    Neither CVE carries CISA KEV fields. There is no cisaExploitAdd, no cisaActionDue, no federal deadline, and no report of exploitation from anyone. What there is, in both cases, is a scored, published, unauthenticated path to command execution and a remediation column that does not close it.

    Why it matters

    An affected-version range that reads “less than 0.3.42, fixed in 0.3.42” is a specific promise, and every downstream consumer of that data treats it as one. A software composition analysis tool clears the finding at 0.3.42. A patch-management queue closes the ticket. None of those systems read the description closely enough to notice that it names two conditions and that the fix version resolves one of them.

    The condition it resolves is the easier one. Binding to loopback narrows exposure to whatever else runs on the same host — which, for a machine whose purpose is running agent workloads in containers, is not a small population. The condition it leaves is the one the CWE assignment actually names: with CONTAINER_NAME unset, the authentication function returns true for everyone. Anything that can reach the socket is authorized. The comment beside it says “local development,” and that is a fair description of the intent, but intent is not a control. A default that fails open is a default that fails open on the machines where nobody read the README.

    This is the shape of failure that keeps turning up in agent infrastructure specifically, and it is worth naming why. The product is a machine that runs arbitrary commands on request. Authentication between the orchestrator and the sandbox is, during development, pure friction: the model is on the same host, the loop needs to be fast, and a token check is one more thing to get wrong. So it gets stubbed out behind an environment-variable test, and the stub becomes the default, and the default ships. The desk has now written variations on this in goose’s recipe scanner skipping the two fields that execute commands, in two Postgres MCP servers losing read-only mode on the same day, and in seven AI coding agents running attacker code out of a repository’s .git/config. The common factor is not carelessness. It is that in this category the dangerous capability is the feature, so the guardrail is always something bolted beside it rather than something the design forces.

    AutoAgent’s version field deserves separate attention. Expressing an affected range as a 40-character git commit hash is honest — the project does not cut releases, so there is no version number to name — but it is unusable by every automated consumer downstream. No scanner can compare an installed tree against a commit range. An operator who installed AutoAgent by cloning the repository in July has no mechanical way to learn whether they are inside the affected set, and no upgrade to perform if they are. In practice that record will sit at 9.8 in every feed that ingests NVD and produce no action anywhere, which is the worst combination available: maximum alarm, zero remediation path.

    One detail cuts against the obvious reading of the Cua timeline. The commit that changed the bind default is a lint-baseline chore, not a security commit. Projects fix things for incidental reasons all the time, but it does mean the record’s remediation field points at a change that was never designed to be a remediation — a reasonable explanation for why it covers half the described flaw.

    What to do

    Cua computer-server. Upgrade to 0.3.45, but do not treat the version number as the control. Set CONTAINER_NAME in the environment so the authentication path is actually exercised. Pass --host 127.0.0.1 explicitly rather than relying on the default, and be aware that invoking the server module directly rather than through the CLI still binds 0.0.0.0. Then confirm from another host that TCP port 8000 does not answer.

    AutoAgent. There is no fix to apply. Do not let Docker publish the sandbox port to 0.0.0.0 — bind the published port to 127.0.0.1 in your own compose or run invocation. Review what the container bind-mounts from the host and narrow it. Do not run it on a shared network segment, a cloud instance with a permissive security group, or a machine where a browser is also running.

    Both. Inventory what is listening on port 8000 across your agent hosts and check whether anything there answers a command without credentials. If you have already recorded CVE-2026-86121 as remediated on the strength of a version number, reopen it.

    Sourcing note

    CVE-2026-86121 and CVE-2026-86124 were read from the NVD API by CVE ID; both show published and lastModified of September 5, 2026, at 10:16 a.m. UTC, and both were confirmed to carry no CISA KEV fields. VulnCheck’s own advisory pages for both were read directly for remediation, credit, and technical detail. The upstream issues, trycua/cua#1892 and HKUDS/AutoAgent#96, were read on GitHub; both showed as open. Release dates for cua-computer-server came from the PyPI JSON API. The claim that Cua’s current code still returns true when CONTAINER_NAME is unset was verified by two separate retrievals of computer_server/main.py on the main branch using different URL forms, because a statement about what code lacks is exactly the kind of claim a single summarized fetch gets wrong.

    Not resolved: whether Cua’s maintainers regard the fail-open local-development default as intended behavior rather than a defect. Neither issue showed a maintainer reply in the content retrieved, and the absence of a reply in a rendered issue page is weaker evidence than a reply’s presence — treat it as unconfirmed rather than as silence. Neither vendor was contacted for this story. Star and fork counts are GitHub’s own figures as displayed on September 5, 2026, and are a measure of attention, not of deployment.