Archon AI coding agent's control API has no login by default — anyone who can reach it can run commands

A critical flaw in Archon, an open-source workflow engine for AI coding agents with more than 23,000 GitHub stars, lets anyone who can reach an Archon server's web interface send instructions to its AI agent — which then runs commands on the host. The flaw is tracked as CVE-2026-111322 and was published on October 15, 2026. No released version changes the risky defaults yet, so anyone running an Archon server should restrict network access to it now.

What happened, in plain English

Archon lets developers describe a software task as a repeatable workflow — plan, write code, run tests, review, open a pull request — and hands each step to an AI coding agent such as Claude or Codex. You can run it on your laptop or on a server, and control it through a web console or an API (application programming interface — the set of web addresses that programs use to talk to it).

According to the CVE record, published by the security firm VulnCheck, that control API at /api/* has no authentication: it does not check who is calling. On top of that, the server by default listens on 0.0.0.0, meaning every network interface of the machine, not just the machine itself. And the AI agent it controls runs with a setting called bypassPermissions, which lets it run commands without stopping to ask a human.

Put together, anyone who can reach the port can type a request to the agent, and the agent will carry it out on the server, with the permissions of the account Archon runs under. That can include reading source code, API keys and tokens stored on the machine.

An analogy: it is like an office assistant who will do anything they are asked, sitting at a front desk with the street door unlocked. There is no exotic trick involved — just a missing lock.

Are you affected? What to do now

Who is affected: anyone running the Archon server (web UI and API) — via archon serve, the Docker image, or a source checkout — that is reachable from other machines. The CVE lists versions 0.2.13 through 0.11.1. Archon has since released v0.12.0 and v0.12.1 (October 17, 2026), but their changelogs do not mention this issue, and the v0.12.1 source still defaults to binding 0.0.0.0 with web login off. Treat current versions as affected until the maintainers say otherwise.

Probably not affected: people who never run the Archon server, or whose server is reachable only from the same machine. If you have never heard of Archon, you have nothing to do.

How to check

• Find Archon instances: look for the process or container (ghcr.io/coleam00/archon), and check the version (the CLI prints it; Docker users check the image tag).
• Check the bind address: in Archon's .env, an unset HOST means 0.0.0.0. Default port is 3090 (the end-user Docker Compose file publishes 3000).
• From another machine, test whether that port answers. If it does, and there is no login in front of it, you are exposed.
• Check whether web login is on: Archon's optional login (Better Auth) is enabled only when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set. SQLite installs cannot enable it.

What to do, in order

1. Cut exposure now: set HOST=127.0.0.1 so the server listens only locally, and/or firewall the port so only trusted hosts can reach it. Never expose it directly to the internet.
2. If others need remote access: put it behind a reverse proxy that requires a login. Archon's own security guidance recommends its Caddy reverse proxy with authentication for public deployments. On Postgres installs, enabling Better Auth makes every /api/* request require a session by default.
3. If the port was reachable from untrusted networks: review Archon's run and conversation history for workflows or chats you did not start, and check the host for unexpected processes or files.
4. Rotate secrets the Archon host could read if you find signs of misuse or cannot rule it out: AI provider API keys, GitHub/GitLab tokens, cloud credentials.
5. Watch for a fix: follow the Archon repository for a release that changes the default bind or requires authentication, then update.

No official indicators of compromise (IOCs) have been published. As of October 18, 2026, the flaw is not in CISA's Known Exploited Vulnerabilities (KEV) catalog, and we found no report of exploitation in the wild.

The expert view

The root cause is CWE-306, missing authentication for a critical function — but the severity comes from the composition. Each design choice is defensible on its own: a bind-all default makes Docker and LAN setups "just work"; authentication is opt-in and tied to Postgres; the agent runs with bypassPermissions because unattended workflows cannot stop for approvals. Combined, the API becomes an unauthenticated remote shell with a natural-language front end.

That last point matters. In a classic unauthenticated-API bug, an attacker must find a dangerous endpoint. Here the dangerous endpoint is the product: sending a chat message to an agent that holds shell access is the intended function. There is nothing to "exploit" in the memory-corruption sense, which is why the CVSS 3.1 score is 9.8 (vector AV:N/AC:L/PR:N/UI:N) and the CVSS 4.0 score 9.3. We think the score is fair for exposed instances. Real-world risk depends on how many servers are reachable beyond localhost; nobody has published a count.

Archon's maintainers clearly understand the bind-address risk: the code already refuses to start on a non-loopback address when GitHub App mode is on, because an internal endpoint hands out live tokens. The same guardrail does not cover the general control API. Archon's docs also steer public deployments to an authenticating proxy. Secure-by-documentation, though, is not secure-by-default — and the default is what most self-hosters run.

This fits a pattern we keep seeing in self-hosted AI infrastructure: Ollama, Mooncake and LightLLM have all shipped internal or control APIs open by default. What changes with agent orchestrators is the payoff. Behind the open port is not a model server but an agent with repository access, provider keys, forge tokens and permission to execute. Any orchestrator of this kind should be treated like a CI runner: private network only, behind authentication, with the least credentials possible.

Still unknown: whether the maintainers acknowledged the report or plan a fix (the repository lists no security advisory); the disclosure timeline; whether v0.12.x is formally in the affected range (VulnCheck's range ends at 0.11.1, the latest release when the CVE was published); and how many instances are internet-facing.

Official sources

• VulnCheck advisory — Archon 0.2.13 through 0.11.1 missing authentication via /api control API (CVE-2026-111322)
• CVE-2026-111322 — CVE record
• Archon repository (coleam00/Archon) and its security policy
• Archon CHANGELOG (v0.12.0 and v0.12.1, October 17, 2026)
• Archon v0.11.1 release
• Coverage: TheHackerWire — CVE-2026-111322 Archon AI agent missing authentication