Archon CVE-2026-111322: An Agent Without Prompts Behind an API Without Auth

As of October 17, 2026.

Turning off a coding agent's permission prompts does not remove the check. It moves the check to whatever can send the agent instructions. In Archon 0.2.13 through 0.11.1, that was anyone who could reach the server's port.

What happened

Archon calls itself "the first open-source harness builder for AI coding." It runs Claude Code, Codex and Pi in workflows triggered from a web console, the CLI, Slack, Telegram and GitHub.

CVE-2026-111322, published October 15 with a CVSS 3.1 score of 9.8, describes the flaw: "Archon 0.2.13 through 0.11.1 contains a missing authentication vulnerability that allows unauthenticated attackers to access the /api/* control API, which binds to 0.0.0.0 by default." VulnCheck's advisory, published the same day, credits the researcher hieuPenguinnn.

The CVE record states the consequence: "Attackers with network access can send messages to the AI coding agent, which runs with bypassPermissions, to execute commands on the host as the Archon user."

Two defaults that met

Two of the pieces were documented.

Archon's security page says it "runs the Claude Code SDK in bypassPermissions mode," so the agent "can read, write, and execute files without interactive confirmation prompts." The reason is sound: workflows run unattended, with no one at a terminal to approve each step.

Its API reference says, under Authentication: "None. Archon is a single-developer tool -- there is no authentication on the API by default." It asks users who expose Archon on a network to put a reverse proxy or firewall in front.

The trouble is the listen address. The researcher's write-up points to const hostname = process.env.HOST || '0.0.0.0' in the server, which listens on every interface unless you set HOST. Archon's web auth turns on only when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set, so a default SQLite install has no gate at all. The write-up lists three request types an unauthenticated client can send to port 3090: post a message to a conversation, start a workflow, and approve a paused run.

So the tool's own docs say "single-developer," and its default bind makes it reachable by everyone on the same network, or the internet if the port is open. An agent that runs commands without asking is now taking orders from that whole audience. Nothing here needs prompt injection or a jailbreak; the agent does what it was built to do for whoever is talking to it.

Patch status

Neither the CVE record nor the VulnCheck advisory names a fixed version. Archon 0.12.0 and 0.12.1 shipped on October 17. Their release notes do not mention the CVE, and the server source at v0.12.1 still defaults to 0.0.0.0, with web auth still off unless both settings are present. 0.12.0 does scope web and CLI conversations to the user who started them when web auth is on, and says "Solo installs behave as before."

Upgrading alone does not close this. The settings below do.

What to do now

1. Bind to loopback. Start the server with HOST=127.0.0.1. If you reach Archon from another machine, use an SSH tunnel or a VPN rather than an open port.
2. Check what is listening. On the host, ss -ltnp | grep 3090 should show 127.0.0.1:3090, not 0.0.0.0:3090 or *:3090. In Docker, check which address the port is published on, since -p 3090:3090 publishes on every interface.
3. Put auth in front of any remote access. Either turn on Archon's web auth (Postgres plus a BETTER_AUTH_SECRET of 32 or more characters) or put a reverse proxy that requires login in front. A firewall rule alone still trusts everyone inside it.
4. Assume compromise on any instance that was reachable. Review conversation and workflow run history for messages and runs you did not start, and approvals you did not give. Rotate what the Archon user could read: provider API keys and subscription tokens, GitHub tokens, SSH keys, cloud credentials and anything in the repositories it worked on.
5. Treat every channel as a shell. Slack, Telegram, GitHub webhooks and the web console all send the agent instructions. Each needs the access control you would put on SSH, because with bypassPermissions it amounts to SSH.

The same trust mistake sits behind ClawJacked and DNS rebinding against local MCP servers: a local agent service assumes only its owner can reach it. Our guide to over-privileged agent tools covers scoping what an agent can do once someone does reach it.