The default is open
Archon is a workflow engine for coding agents: you define development work as YAML workflows, and it drives Claude Code, Codex or Pi through planning, implementation, validation and review, with a web console started by archon serve. That console is the problem.
CVE-2026-111322, published by VulnCheck on October 15, covers versions 0.2.13 through 0.11.1. Read the code at that tag and the posture is not subtle. The server takes its bind address from an environment variable and falls back to 0.0.0.0: it accepts connections addressed to any of the host's IPv4 interfaces, subject to whatever firewall rules and network segmentation the operator has in place. Authentication is opt-in. Per the project's own auth configuration at that tag, web auth turns on only when both a Postgres database URL and an auth secret are present — which a stock install, running on SQLite with no secret, does not have. When the gate is off, the API middleware lets requests through. The project's own .env.example documents the escape hatch in one line: set the host to 127.0.0.1 to restrict it to localhost only. It is documented as an option because it is not the default.
What sits behind that open door is a control plane, not a status page. Per the researcher's writeup, a client that can reach port 3090 with no credentials can start a workflow run, create a conversation and inject messages the agent treats as operator input, and approve or reject the actions the agent paused to ask about. That last route is the one to sit with. The pause-and-approve step is the human check in an Archon workflow. If the routes behave as the code indicates, an unauthenticated caller could approve actions that were meant to require an operator's say-so — undermining the human-approval boundary without ever obtaining an interactive shell. Whether a given approval is accepted, what workflow state it changes and what ends up in the log were not demonstrated: the finding comes from reading the code, not from exercising it against a live instance.
Two scores, one steering wheel
Now the part the headlines flatten. VulnCheck's advisory says an attacker with network access can send messages to the agent, "which runs with bypassPermissions", to execute commands on the host as the Archon user, and scores the flaw 9.3 under CVSS 4.0. The CVE record carries a separate 9.8 under CVSS 3.1. Both numbers are published severity assessments of what the flaw could allow. Neither is a report of an observed exploit. Anthropic's own documentation for Claude Code describes bypassPermissions as the mode where everything runs without asking, recommended for isolated containers and virtual machines only.
The researcher who found the flaw, credited as hieuPenguinnn, reads it more narrowly, and says so plainly: this is not remote code execution on the host, runtime validation was not performed, and the example requests were not executed against a live instance. Their own rating is high, not critical.
Both readings can hold at once, and the distinction is worth keeping because it decides what you do next. An HTTP request to Archon does not hand anyone a shell. What it can hand them, on the code as written, is the steering wheel of an agent that may already be allowed to run shell commands, hold your provider keys and act on your repositories. How bad a hijacked run would be depends on what your workflows permit — the blast radius was configured by whoever set the agent up, usually for convenience. As of October 16 there was no public exploit, and the CVE was not in CISA's known-exploited catalogue. The route list in a public writeup is most of a recipe, so that status should not be read as breathing room.
There is also a history here. In May, OX Security reported CVE-2025-69443 in the earlier Archon OS line, versions 0.1.0 through 0.3.11: a backend reachable with no authentication and no CORS protection, which a malicious web page could reach. Per OX, the maintainer's position then was that the app is meant to run locally. A tool can be meant to run locally and still listen on every interface. Intent is not a bind address.
What to do until a patch exists
As of October 16, v0.11.1, the last affected version, was still the latest release, and the repository's security page listed no advisory. Until a patched release ships, the mitigations are the project's own documented ones.
Check the bind first, and be precise about what it means. If Archon is listening on 0.0.0.0:3090, it accepts connections addressed to any of the host's IPv4 interfaces; whether a particular machine can actually connect still depends on firewalls, security groups and segmentation. Binding to 127.0.0.1:3090 restricts direct IPv4 access to the local loopback interface. Set HOST=127.0.0.1 in the environment and restart archon serve. In Docker, do the restriction at publish time — 127.0.0.1:3090:3090 — because the container itself has to listen on its own interfaces. And check the rest of the container setup while you are there: other published ports, host networking mode, any reverse proxy in front. Binding one published port to loopback is not a substitute for checking every route by which the service can be reached.
Then, for anything shared, configure the authentication the project supports. Per the code, the gate needs both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET of at least 32 characters. When web auth is enabled the API gate defaults to on; ARCHON_WEB_AUTH_REQUIRED=false explicitly turns that server-side gate off, so do not set it unless an authenticating proxy genuinely sits in front. Treat setting the variables as the start, not the proof: the database has to be functional, the sign-in flow correctly configured, and the protected routes actually enforced. Archon's own SECURITY.md already says to use the Caddy reverse proxy with authentication when deploying the server publicly. For this flaw, a team server on office Wi-Fi counts as public.
Verification is two separate checks, and the first cannot do the second's job. Reachability: from a second machine on the relevant network, test whether the service still answers. The /api/health route sits on the gate's public allowlist — it is meant to answer without a sign-in — so a health response can establish that the service remains reachable, but it cannot verify authentication, because that route is intentionally public. Authentication: separately, send an unauthenticated request to a protected, non-health route, such as a run or approve endpoint, and confirm it is rejected. Loopback, meanwhile, is a stopgap, not a finish line, because with the gate off, any process on the same machine can still drive the API.
The researcher's suggested fix is small enough to name: default to 127.0.0.1, require a local token on mutating routes even when web auth is off, and warn at startup on a non-loopback bind without authentication. Until some version of that ships, the general lesson travels well beyond one repository. Agent harnesses are servers now. They hold keys, they run commands, and they have approve buttons. The first security question to ask of any of them is the oldest one on the network: what address does it bind to, and who can reach it?
Sources
- [1] VulnCheck advisory, "Archon 0.2.13 through 0.11.1 Missing Authentication via /api/* Control API" (CVE-2026-111322, October 15, 2026) — source for the CVE description, the bypassPermissions command-execution framing and the 9.3 CVSS 4.0 scoreRead source
- [2] CVE record for CVE-2026-111322, via CVEFeed — source for the 9.8 CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), the CWE-306 classification and the code references at tag v0.11.1Read source
- [3] Gabriel Anhaia, "Archon's Agent Control API Has No Login by Default and Listens on 0.0.0.0. No Patch Yet", DEV, October 16, 2026 — analysis quoting the project's code at v0.11.1: the HOST default, the two-variable auth gate, the middleware pass-through, the route list and the October 16 status checksRead source
- [4] Researcher writeup by hieuPenguinnn (HackMD, linked from the CVE record) — the credited researcher's own account, including the not-RCE caveat and the absence of runtime validationRead source
- [5] Archon repository (coleam00/Archon), including SECURITY.md, .env.example and the auth configuration at tag v0.11.1Read source