The Gate Was Off by Default: CVE-2026-111322 Leaves Archon’s Agent Control Plane Open on 0.0.0.0
AI coding harnesses are network servers that happen to have an agent attached. CVE-2026-111322, published 15 October 2026, is what happens when the server treats authentication as an upgrade path and the agent as the payload: in coleam00/Archon (23,692 stars), the default install ships an HTTP control API with no authentication, bound to 0.0.0.0:3090, behind which sit the routes that start workflow runs, inject messages into agent conversations, and approve or reject the agent’s paused actions. VulnCheck rates it 9.8 critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H; CVSS 4.0 9.3) under CWE-306 (Missing Authentication for Critical Function). Affected: ≥ 0.2.13, ≤ 0.11.1. Fixed: no fixed version named at the time of writing — v0.11.1 (25 September 2026) is still the newest release.
The finding comes from researcher hieuPenguinnn, written up as a source-review report with complete file and line references, and carried as a VulnCheck advisory the same day the CVE published. Like the Junie CLI project-scope MCP flaw disclosed the same week, the mechanism is deterministic infrastructure, not model misjudgement: no prompt injection is required, because no identity is ever demanded.
Three defaults that combine into an open control plane
We read the pinned source at tag v0.11.1 first-hand, and each of the three facts checks out exactly as the report states. First, the server binds to every interface. In packages/server/src/index.ts:
const hostname = process.env.HOST || '0.0.0.0';
The shipped .env.example confirms it (“Bind address (default: 0.0.0.0). Set to 127.0.0.1 to restrict to localhost only”) with the default port 3090. Second, the single middleware guarding every /api/* route is a no-op when the gate is disabled. In packages/server/src/routes/api.ts (lines 1748–1756):
const PUBLIC_API_GATE_PREFIXES = ['/api/auth/', '/api/health'];
app.use('/api/*', async (c, next) => {
if (!isApiGateEnabled()) return next();
const path = c.req.path;
if (PUBLIC_API_GATE_PREFIXES.some(p => path === p || path.startsWith(p))) return next();
const ctx = await resolveAuthContext(c);
if (!ctx) return apiError(c, 401, 'Authentication required');
return next();
});
Third, the gate defaults to disabled. In packages/server/src/auth/config.ts:
export function isApiGateEnabled(env: NodeJS.ProcessEnv = process.env): boolean {
return isWebAuthEnabled(env) && env.ARCHON_WEB_AUTH_REQUIRED !== 'false';
}
And isWebAuthEnabled() requires both a DATABASE_URL and a BETTER_AUTH_SECRET — which a default SQLite solo install never sets. So the 401 branch is dead code on every default deployment, and the conversation, workflow-run, approval, and provider-key routes registered behind that middleware answer to anyone who can reach the port.
What an unauthenticated caller can actually do — and what is not established
The report is admirably disciplined about the boundary between source fact and speculation, and we preserve it. Established from source: a network caller with no account and no token can start workflow runs, send messages into agent conversations as if they came from the operator, approve or reject the agent’s paused actions, and connect or disconnect provider keys (breaking model access or pointing the instance at an attacker-controlled key). The CNA description goes one step further, stating the attacker can send messages to the AI coding agent, “which runs with bypassPermissions, to execute commands on the host as the Archon user.”
Not established, by the researcher’s own statement: this is not remote code execution on the host as a property of the HTTP API. No instance was started, no request was sent, no response captured — the finding is source review, and the severity of a driven run depends on the workflows and agent configured on that instance. The provider-key list route returns metadata only, so bulk secret read-back through the HTTP response is not established either. The two configurations that remove the finding are equally crisp: enable web auth (both DATABASE_URL and BETTER_AUTH_SECRET, at which point the gate enforces 401s), or set HOST=127.0.0.1 so the open gate is not network-reachable. The shipped default is neither.
Note the quiet indictment inside the codebase itself. The same index.ts already carries a fail-fast guardrail that refuses to boot when the /internal/git-credential endpoint — which hands out live installation tokens — would land on a non-loopback bind. The project understood that a public bind is dangerous for one endpoint, and shipped the hard refusal for it, while the entire agent control plane stayed behind a gate that defaults to off. One endpoint got a fail-closed default; the more powerful one got documentation.
The timeline, from published records
- 25 September 2026, 16:45:47Z — v0.11.1 (“Archon CLI v0.11.1”) published. Still the newest release at the time of writing.
- 15 October 2026 — VulnCheck advisory published (severity critical, affecting ≥ 0.2.13, ≤ 0.11.1, CWE-306, credit hieuPenguinnn), referencing the researcher’s writeup and the three source locations.
- 15 October 2026, 22:19:30Z — CVE-2026-111322 published; NVD ingestion with status “Received,” source
disclosure@vulncheck.com, both CVSS vectors, no independent NVD analysis at the time of writing. - 15 October 2026 — upstream
mainremains active (including an auth-adjacent fix, “operator chats are private to the user who started them,” #4224), but no release carrying a fix has been tagged.
Two scoping notes for the record. This is a different defect from CVE-2025-69443, the unauthenticated web-to-client attack on the archived Python backend — different codebase, different finding; do not merge their remediation. And there is no public vendor advisory for this defect in the TypeScript product at the time of writing; the VulnCheck advisory and the researcher writeup are the disclosure record.
The pattern here is the one we keep documenting across agent infrastructure: the control plane that drives the agent is the highest-value endpoint in the deployment, and it keeps inheriting the threat model of a local dev tool. Compare Astron Agent’s unsandboxed code node, where the dangerous default was the executor, and the protocol-pivoting SSRF chain across five MCP servers, where the dangerous default was the fetch tool’s reach. In Archon the dangerous default is the bind address combined with an auth gate that only exists when the operator builds the database for it. The fix the researcher proposes is correspondingly structural: bind loopback by default with explicit opt-in for network exposure, require a local token for mutating /api/* routes whenever full web auth is off, and warn at startup when the server listens beyond loopback with the gate disabled.
What to do
- Do not expose port 3090 to any network you do not fully trust. Until a fixed release exists, treat every default-configured Archon server as an open agent control plane.
- Set
HOST=127.0.0.1unless a reverse proxy genuinely needs a non-loopback upstream — and if it does, enforce authentication at the proxy layer. - Enable web auth (Postgres
DATABASE_URLplus a strongBETTER_AUTH_SECRET, minimum 32 characters per the boot assertion) soisApiGateEnabled()returns true and the 401 branch actually runs. - Audit for prior access: unexpected workflow runs, unfamiliar conversation messages, approved-then-denied action pairs you did not touch, and provider-key changes. There is no evidence of exploitation, but agent-plane abuse leaves application-level traces, not crashes.
- Rotate provider keys if the instance was ever network-reachable in the default configuration — keys can be disconnected and replaced by anyone who reached the API.
- Watch the repository for a release newer than v0.11.1 naming CVE-2026-111322; upgrade on arrival rather than hand-rolling the gate patch.
Verification note: we confirmed CVE-2026-111322 against the NVD 2.0 API (published 2026-10-15T22:19:30.633Z, vulnStatus Received, source disclosure@vulncheck.com, CVSS 3.1 9.8 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CVSS 4.0 9.3, CWE-306, six references) and against the VulnCheck advisory (critical, 10/15/2026, affecting Archon ≥ 0.2.13, ≤ 0.11.1, credit hieuPenguinnn). We read packages/server/src/index.ts (bind-host line), routes/api.ts (gate middleware, lines 1748–1756), and auth/config.ts (isApiGateEnabled) at tag v0.11.1 first-hand via the repository and quote them verbatim, and confirmed the .env.example bind default and port. Release history (v0.11.1 newest, 25 September 2026 16:45:47Z), repository metadata (23,692 stars, 3,510 forks), and post-tag commit activity including #4224 come from the GitHub API. The researcher’s impact limits, verification limits, fix proposal, and no-runtime-validation statement are reported as the writeup states them, not re-derived. Brave Search was used for discovery only. We started no Archon instance, sent no requests, and executed no exploit. We found no evidence of exploitation and do not imply any.
Sources:
- NVD — CVE-2026-111322 (published 15 October 2026; Received at the time of writing)
- VulnCheck advisory — “Archon 0.2.13 through 0.11.1 Missing Authentication via /api/* Control API” (CVE-2026-111322, critical; 15 October 2026)
- hieuPenguinnn — “Archon OS control API has no authentication by default and binds to all interfaces” (source-review writeup)
- coleam00/Archon — packages/server/src/routes/api.ts at v0.11.1 (the /api/* gate)
- coleam00/Archon — packages/server/src/auth/config.ts at v0.11.1 (gate enablement)