Archon: the agent control API answers unauthenticated callers
Archon's control API accepts conversation and workflow calls from anyone who can reach it in a default SQLite install.
· VulnCheck · Research by hieuPenguinnn
Archon, an open-source harness builder for AI coding, serves its /api/* control API with no authentication in a default install, on every network interface. VulnCheck rates it CVSS 9.3. No fixed release is listed.
01What happened
VulnCheck published CVE-2026-111322 for Archon on October 15, 2026, crediting the finder hieuPenguinnn. The finder's write-up reports the flaw from reading the source of release v0.11.1, and states that no instance was started and no requests were sent. Archon is Cole Medin's open-source harness builder for AI coding agents.
02How it works
Three defaults line up. The server falls back to binding 0.0.0.0 when the HOST variable is unset, so it listens on every interface. The /api/* middleware returns without resolving an identity unless the API gate is enabled, and that gate requires both DATABASE_URL and BETTER_AUTH_SECRET, neither of which a default SQLite install sets. Routes that start conversations, send messages to the agent and run or approve workflows are then open to any caller.
03Who is affected
Versions 0.2.13 through 0.11.1 are listed as affected, which includes v0.11.1, the current release. Exposure needs the default SQLite configuration, no HOST override, and an attacker who can reach the service over the network. Installs that set a Postgres DATABASE_URL and a signing secret switch the gate on, and binding to loopback removes the network reach.
04What to do
Set HOST to 127.0.0.1 so Archon listens on loopback only, or configure both DATABASE_URL and BETTER_AUTH_SECRET and leave ARCHON_WEB_AUTH_REQUIRED unset so the gate enforces an identity on every mutating route. Check whether the service port is reachable from outside the host.
Questions people ask
- Is Archon affected by CVE-2026-111322 in a default install?
- Archon installs that use the default SQLite setup are affected, because the /api/* authentication gate only switches on when both DATABASE_URL and BETTER_AUTH_SECRET are set. A default install sets neither, so the middleware skips the identity check. The server also binds 0.0.0.0 when HOST is unset, which puts the control API on every network interface.
- Is there a patch for the Archon control API flaw?
- No patched Archon release is listed. VulnCheck names 0.2.13 through 0.11.1 as affected, and v0.11.1, published on September 25, 2026, is still the latest release. Operators have to mitigate through configuration: bind the server to loopback using HOST, or set DATABASE_URL and BETTER_AUTH_SECRET so the gate enforces an identity on mutating routes.
- Did the researcher demonstrate remote code execution in Archon?
- hieuPenguinnn's write-up does not claim remote code execution, and reports no runtime testing: no instance was started and no requests were sent. VulnCheck's advisory goes further, saying a network attacker can message the AI coding agent, which runs with bypassPermissions, and execute commands as the Archon user. The finder says impact depends on the workflows and agent configured.
- Which Archon endpoints accept unauthenticated requests?
- The write-up lists conversation creation, conversation messages, workflow runs, the workflow approve and reject routes, and the provider update and delete routes under /api/auth/providers as reachable without authentication under default settings. Only the health route and /api/auth/* sit on a deliberate public allowlist. Reading stored provider secrets back through the API is not established, the author notes.
Sources 5 links, all fetched
- 1vulncheck.comVulnCheck Advisory
- 2hackmd.ioResearcher Write-Up
- 3cveawg.mitre.orgCVE Record
- 4github.comGitHub Advisory
- 5github.comAuth Gate Source