AutoAgent, the HKUDS agent framework, runs its tool calls inside a Docker container and talks to that container over a TCP control channel. Per NVD, that channel binds to every interface, requires no authentication, and executes whatever it receives as root. NVD scores it CVSS 3.1 base 9.8 on the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, and classifies it as CWE-306, missing authentication for a critical function.
The exploitation report is single-sourced. VulnCheck’s KEV catalog listed CVE-2026-86124 on September 18, 2026 and flags exploitation as active. CISA’s Known Exploited Vulnerabilities catalog does not carry it as of our most recent CISA KEV ingestion on September 19, 2026, so no Binding Operational Directive 26-04 obligation attaches. That is a statement about catalog membership, not a judgement that CISA looked and declined.
The sandbox was never the boundary it looked like
Agent frameworks containerise tool execution for a specific reason: a language model that can be talked into running a destructive command should be running it somewhere disposable. The container is there to contain the model.
This CVE is what happens when that reasoning stops one layer short. The container bounds what the agent’s own output can reach. It says nothing about who is allowed to inject output into it in the first place — and per NVD’s description, the answer here was anyone who could reach the port. The isolation primitive was real; the admission control in front of it was absent. An operator reading the architecture would see “sandboxed execution” and be substantially correct about the threat the design was built for, and substantially wrong about this one.
NVD’s description goes further than container-internal impact: commands run as root inside the container, and the container carries bind-mounted host workspace directories. Whatever the agent was given read/write access to on the host — repositories, credentials files left in a project tree, build outputs — sits inside that mount.
An assessment on the scope metric
This is Quietlytic analysis rather than a sourced claim, and we flag it as such.
The NVD vector carries S:U, scope unchanged, which asserts that impact stays within the vulnerable component’s security authority. Read strictly against the container, that is defensible. Read against the bind mounts NVD’s own description names, it is arguable: a write into a host directory is an effect outside the container’s authority, which is the condition S:C exists to express. We are not asserting the score is wrong — CVSS scope is a notoriously contested metric and reasonable analysts split on exactly this pattern. We are saying that at 9.8 the score is already near ceiling, so the distinction changes little operationally, and that anyone modelling blast radius should reason from the mount configuration rather than from the scope letter.
There is no fixed version in our data, and that shapes the response
Our ingested record carries no fixed release and no affected version range. The references NVD supplies are the project repository, two specific source files pinned to a commit — the Docker environment module and the TCP server module — and an issue in the project’s tracker. A tracker issue is not a release.
So the honest remediation guidance is not “update to version X,” because we cannot name X from evidence. It is network containment: ensure the control port is not reachable from anything other than the loopback interface or an explicitly trusted host, and verify that directly rather than assuming a deployment default did it. Operators running AutoAgent inside a broader orchestration stack should also audit what the host workspace mount actually exposes, since that mount — not the framework version — determines how far a compromise travels.
This product class keeps producing the shape. Quietlytic’s coverage of nine CodeWhale AI coding-agent CVEs earlier this month spans both halves of it — approval-gate failures and sandbox failures, including two paths where an action was auto-approved rather than escaped. Worth naming as a pattern: the isolation tends to get the engineering attention, and the thing deciding who gets to reach into it tends not to.
What we don’t have
- No CISA KEV listing as reflected in our ingestion through September 19, 2026.
- No EPSS score. FIRST’s model has no published probability for this CVE in our data, so we cannot offer an exploitation-likelihood figure alongside the severity one.
- No fixed version and no affected version range — see above.
- CVSS is single-sourced. The 9.8 and its vector come from NVD alone; no second ingested source scores this CVE, and there is no recorded conflict.
- No independent corroboration of exploitation. VulnCheck’s catalog is the only source in our data asserting it, which is why this record is rated medium confidence rather than high.
Frequently Asked Questions
What is CVE-2026-86124? A critical (CVSS 9.8) missing-authentication flaw, CWE-306, in HKUDS AutoAgent. The framework’s sandbox TCP server binds to all interfaces without authentication and executes received commands as root inside the agent container, which carries bind-mounted host workspace directories.
Is CVE-2026-86124 being actively exploited? It is reported as exploited by one source. VulnCheck’s KEV catalog listed it on September 18, 2026 with exploitation marked active. No second source in our data corroborates that, so we rate confidence medium.
Is CVE-2026-86124 on the CISA KEV catalog? Not as of our most recent CISA KEV ingestion on September 19, 2026. Federal agencies therefore have no BOD 26-04 remediation deadline for it, though the severity and unauthenticated reach argue for prioritising it regardless.
How is CVE-2026-86124 fixed? Our ingested data names no fixed release. Until one is confirmed, the available mitigation is network-level: restrict reachability of the agent’s control port and audit what the container’s host bind mounts expose.
Data sourced from the National Vulnerability Database (NVD) and VulnCheck KEV, aggregated September 19, 2026. See more vulnerability intelligence.