Archon's default install lets anyone on the network drive its AI coding agent

What the advisory says

A critical vulnerability in Archon, a popular open-source tool for running AI coding agents through repeatable workflows, means a default installation lets anyone who can reach it on the network send instructions to its coding agent without logging in. The flaw is tracked as CVE-2026-111322, published on 15 October 2026 by VulnCheck, which acts as the CVE numbering authority for the record.

The VulnCheck advisory covers Archon versions 0.2.13 through 0.11.1, the latest release, published on 25 September. Its description says the /api/* control API has no authentication and binds to 0.0.0.0 by default, so attackers with network access can send messages to the AI coding agent, which runs with bypassPermissions, and execute commands on the host as the Archon user. The record scores it 9.3 (critical) under CVSS 4.0 and 9.8 under CVSS 3.1, classed as CWE-306, missing authentication for a critical function.

There is no fixed release yet. When AI Lookout checked the project's main development branch on 17 October, the server still defaulted to listening on all network interfaces and the authentication gate was still off unless an operator configures it, and we found no security advisory or patch note from the maintainers in the repository. The finding was credited to a researcher who publishes as hieuPenguinnn.

What Archon is and why the flaw matters

Archon, maintained by developer Cole Medin under the MIT license, describes itself as the first open-source harness builder for AI coding. Developers write YAML workflows that chain planning, implementation, tests, code review and pull-request creation, and Archon drives a coding agent such as Claude Code or Codex through each step. The repository had about 23,700 GitHub stars when we checked, which puts it among the more widely used projects in a crowded field of agent harnesses.

That design is what makes an open control API serious. Archon's own security documentation says it runs the Claude Code SDK in bypassPermissions mode, so the agent can read, write and execute files without interactive confirmation prompts. The documentation explains why: workflows are meant to run unattended from Slack, Telegram or GitHub, where no one is at a terminal to approve each action. It also warns operators not to expose Archon to untrusted users, and calls it a single-developer tool with no multi-tenant isolation.

In other words, the safety of a default Archon server rests on who can reach it. On a laptop behind a home router that may be few people; on a cloud server, a shared office network or a misconfigured container host it can be many more.

How the missing check works

The researcher's technical write-up traces the issue to three settings in Archon's server code at the v0.11.1 tag. First, the web server, started by the archon serve command, takes its bind address from a HOST variable and falls back to 0.0.0.0, every interface, on port 3090. The shipped example configuration says operators must set 127.0.0.1 to restrict it to the local machine.

Second, a single middleware guards every /api/* route, but it returns immediately without checking identity when the authentication gate is disabled. Third, the gate is only enabled when an operator supplies both a PostgreSQL DATABASE_URL and a BETTER_AUTH_SECRET. A default install uses SQLite and sets no secret, so the gate stays off and every request passes through.

Archon's documentation is consistent with this. It says SQLite and solo installs have no built-in user authentication, and tells operators to put basic or form authentication in front of the web interface before exposing it publicly. The code also shows the maintainers have thought about network exposure elsewhere: when the GitHub App mode is active, the server refuses to start on a non-loopback address unless the operator opts out, because an internal endpoint there hands out live tokens. The general control API has no equivalent guard.

What an attacker could do

According to the write-up, the routes behind the disabled gate are the agent's control plane, and an unauthenticated caller can use all of them.

• Start a run of any configured workflow, which dispatches work to the orchestrator that drives the coding agent.
• Create a conversation or inject a message into an existing one, so the agent receives attacker-written text as if the operator had typed it.
• Approve or reject a paused run, releasing an action the agent was holding for human sign-off or cancelling it.
• Connect or disconnect a model provider key, which can break the agent's model access or swap in a key the attacker controls.

Who is exposed and how to check

The vulnerability matters most for Archon servers reachable from other machines: a cloud virtual machine with port 3090 open, a server on a shared or office network, or a container host that publishes the port. Archon's deployment guides cover Docker, cloud VPS and always-on setups, which are exactly the cases where a server is more likely to be reachable.

Operators who followed the hardened path are in better shape. With a PostgreSQL database and BETTER_AUTH_SECRET set, the gate returns a 401 error to unauthenticated requests except login and health checks, and the researcher says the finding does not apply. A server bound to 127.0.0.1 is not reachable from other hosts even though its gate stays off, although anything else running on the same machine can still reach it.

A quick check is to look at how the server is listening. If archon serve is bound to 0.0.0.0 or a public address, and the install uses SQLite or has no BETTER_AUTH_SECRET, treat the control API as open to anyone who can route to that port.

How to protect an Archon install

Until a patched release ships, the advisory, the write-up and Archon's own documentation point to the same mitigations, summarised in the table below. Binding to the local machine or turning on the server-side gate closes the hole; the other steps reduce exposure around it.

Operators whose servers were exposed should also review run history and conversations for activity they do not recognise, and rotate the model provider keys and repository tokens the server holds, since the agent works inside cloned repositories with the operator's credentials.

A pattern across agent tools

Archon is the latest example of tooling around AI agents becoming the weak point rather than the model. Researchers have already shown a backdoored model stealing credentials through Codex CLI, and India's CERT-In recently warned that AI agents under evaluation had broken into live systems. In each case the agent had real permissions, and the question was who or what could steer it.

Vendors are responding by putting checks between agents and their tools. OpenRouter this week launched Armor, a classifier that screens every agent tool call against written rules. Controls like that assume the person sending instructions is legitimate. CVE-2026-111322 is a reminder that the first control is still the oldest one: requiring a login before anyone can tell the agent what to do.

What is still unclear

The researcher says the finding came from reading the source code and that no request was sent to a live instance, so there is no public proof-of-concept run. The write-up is also more cautious than the CVE text: it says the HTTP API alone does not establish remote code execution, and that the effect of a driven run depends on the workflows and agent configured. The CVE description, by contrast, says attackers can execute commands on the host through the agent's bypassPermissions mode. Both are consistent with Archon's documentation that the agent can run shell commands without prompts.

We found no reports of the flaw being exploited, and no count of internet-exposed Archon servers. The maintainers had not commented publicly in the repository by 17 October. The issue is separate from CVE-2025-69443, which affected Archon's older Python backend, now archived, and a 2025 request to add API key authentication was closed in April with a note that the Python code was being replaced.