CVE-2026-111322: Archon's Control API Ships With No Auth on 0.0.0.0, CVSS 9.8

This is a black week for the agent toolchain. Just as OpenCode admitted its Console breach — 1.4% of users' API keys possibly exposed (see n1 in this batch) — a deeper fault line cracked open: CVE-2026-111322. The /api/* control API of Archon, the open-source AI coding workflow engine, ships with no authentication by default and binds to 0.0.0.0. CVSS 3.1 score: 9.8 out of 10. Anyone who can reach your network can send messages to your coding agent and have it run arbitrary commands on the host with bypassPermissions.

The flaw was published by security firm VulnCheck on October 15, and the CVE record entered the database the same day. As of October 16, the official repo's security page carried no advisory, and the latest release v0.11.1 was still affected — no patch. And Archon is no obscure toy: 23.7k GitHub stars, calling itself "the first open-source harness builder for AI coding," driving Claude Code, Codex and Pi through YAML-defined development workflows.

1. What the bug is: a lesson in three lines of code

The CWE is 306: "Missing Authentication for Critical Function." In plain language: Archon has a control API (/api/*) that shows workflow progress in your browser when you run archon serve — a dashboard meant for "local viewing" that by default listens on 0.0.0.0, i.e. visible to the entire network, with no login whatsoever.

The CVE record pins the problem to three code locations: packages/server/src/auth/config.ts#L25-L27 (auth config), src/index.ts#L909 (service binding), src/routes/api.ts#L1749-L1756 (API routes). Researcher hieuPenguinnn's HackMD writeup documents the exploit chain; VulnCheck's advisory states it plainly: "binds to 0.0.0.0 by default," and attackers can "send messages to the AI coding agent, which runs with bypassPermissions, to execute commands on the host as the Archon user."

Note the deadliest link in the chain: bypassPermissions. Archon's agents run with permission prompts skipped by default — so workflows can run unattended. But once the control plane is exposed, that "productivity feature" becomes "the attacker needs no social engineering and no privilege escalation, just orders for an agent that holds a shell and never asks 'are you sure.'" The CVSS vector AV:N/AC:L/PR:N/UI:N translates to: network-reachable, easy to attack, no privileges needed, no user interaction — that's where the 9.8 comes from.

Affected versions: 0.2.13 through 0.11.1. From the version that introduced this control API all the way to today's latest release — the entire range.

The disclosure timeline is worth noting too: researcher hieuPenguinnn published technical details on HackMD first; VulnCheck issued the formal advisory on October 15; the CVE record entered the database the same day (2026-10-15T22:19:30Z). On October 16, the CVE's SSVC assessment was updated: exploitation marked "poc" (proof of concept exists), automatable marked "yes." Translation: from the moment the advisory dropped, the barrier to weaponization was gone — public PoC plus automatable means scanners and mass-exploitation tooling are only a matter of time. Yet the official repo's security page still shows no advisory. Incident response is clearly lagging disclosure.

2. Why agent tools keep failing at "secure by default"

Put Archon next to OpenCode and an uncomfortable pattern emerges: agent tools' defaults are optimized for demos, not for security.

Think about it: why did Archon's developers bind the API to 0.0.0.0? Because "run it and watch in the browser" is the smoothest demo experience. Why no auth? Because "a login for a little local service" would scare off new users. Every default serves growth — until someone exposes that default service to an untrusted network. Gabriel Anhaia's dev.to headline says it straight: "Archon's Agent Control API Has No Login by Default and Listens on 0.0.0.0. No Patch Yet."

This is no isolated case. Recall the agent-tool security news of the past half year: MCP servers running with permissive defaults, agent shell tools without sandboxes, prompt injection via web content — nearly every root cause was "defaults that trust too much." Traditional software took twenty years to learn "secure by default"; the agent toolchain is paying that tuition again, except this time the unit of tuition is "an AI that can execute commands directly."

The deeper problem is the asymmetry of capability and control: the whole point of a harness layer like Archon is making agents more autonomous and less interruptive — YAML-defined workflows, automatic progression, automatic approval clicks. It removes human confirmation from the loop in exchange for efficiency, while the security model still assumes "it's running on my own machine." When "my own machine" becomes "a machine on the company LAN or café Wi-Fi," that assumption shatters. Attackers don't need to hack your computer — just your network. In a coffee shop, a shared apartment or a conference room, that's not hard.

3. What to do now: a three-step self-check

There's no official patch, but three things can be done immediately:

First, check whether you're running Archon. If you've run archon serve, look at the bind address right now. If it's 0.0.0.0, rebind to 127.0.0.1 immediately, or put an authenticated reverse proxy (Caddy/Nginx with basic auth — five minutes of work) in front. That's the core of VulnCheck's "Solution" section: upgrade to a fixed version (doesn't exist yet) + restrict control-API access + review all network interfaces.

Second, don't expose agent services to untrusted networks. This generalizes to every agent tool: OpenCode, Archon, MCP servers of all kinds, local model APIs — listen on localhost by default; use SSH tunnels or encrypted mesh networks like Tailscale for remote access. Remember the AV:N in the CVSS vector (network-reachable): attackers don't even need to touch your machine.

Third, re-evaluate "no-confirmation" switches like bypassPermissions. Archon's agents default to bypassPermissions for workflow smoothness. But ask yourself: does this agent hold a shell? Is the network it sits on trustworthy? If the answers are "yes to shell" and "no to trust," that switch is a door left open for attackers. At minimum: force confirmation back on in untrusted networks, or put the agent's execution inside a sandbox (Docker, gVisor, microVMs) so the blast radius of "execute a command" stops at the container wall.

4. Three judgments for vibe coders

First, add "default-config audit" to your unboxing routine. From now on, every time you install an agent tool, before running the demo, do three things: ss -tlnp to see what it's listening on, read the auth-related defaults, and search for known CVEs. Archon's lesson: star count (23.7k) and "secure by default" are completely uncorrelated metrics. Popular does not mean safe — especially in the agent-tool category of "get it running first."

Second, the harness layer is the next security disaster zone — position early. Model-layer security (alignment, jailbreaks) has big labs competing; agent-body security (prompt injection, tool permissions) is getting attention. But the harness/orchestration layer — workflow engines like Archon that make agents more autonomous — is still largely wilderness. And it's precisely the most dangerous layer: it holds scheduling power over multiple agents, defaults to unattended operation, and usually runs with the highest privileges. If you're a vibe coder building agent infra, security tooling in this direction (secure-by-default harness templates, control-plane auth scaffolding, agent behavior auditing) is blue ocean right now.

Third, read this week's two incidents together. OpenCode lost keys on the "hosted side" (trusting the vendor's servers); Archon left the "control plane" wide open (trusting the local network). One-line summary: in the agent era, the "default trust" list is being voided item by item — trust no vendor, trust no local network, trust no defaults. Zero trust isn't a slogan; it's the checklist you should run in your head before your next npm install of an agent tool.

5. Appendix: a local-service hardening checklist for vibe coders

Archon's failure isn't an isolated case — "bound to 0.0.0.0 by default, no auth" is endemic among local dev tools. Pin this checklist to your desk and run it for every new tool you install; ten minutes buys real peace of mind:

1. First, see who it's listening to. Scan listening ports with ss -tlnp (or lsof -i -P on macOS); rebind every 0.0.0.0 management/control port to 127.0.0.1. Only open up for LAN access when needed — and never without auth.

2. Always put a door in front of the control plane. Any local service with "control," "admin" or "dashboard" in its name gets a reverse proxy (Caddy/Nginx) with basic auth or tokens before it's exposed. Archon's lesson: the first item in VulnCheck's advisory "Solution" section is restricting control-API access — with no official patch, you are the patch.

3. Reach services remotely through tunnels, not the public internet. Need to reach your home agent service from outside? Use SSH port forwarding or an encrypted mesh like Tailscale — never map the port straight to the public internet. Remember the AV:N in the CVSS vector: attackers don't need to touch your machine; reaching your network is enough.

4. Grade no-confirmation switches by network environment. Switches like bypassPermissions are understandable on a trusted LAN — but the moment you join café, conference-room or shared-apartment Wi-Fi, turn them off, or move the agent's execution into a sandbox (Docker, gVisor, microVMs) so the blast radius of "execute a command" stops at the container wall.

5. Keep a "security file" per tool. After installing, record three lines: bind address, auth method, known CVEs. Search CVEs and the official security advisory quarterly — Archon's official repo still has no advisory; incident response is clearly slower than disclosure. Trust yourself before you trust the vendor.

We'll keep tracking Archon's fix — the CVE's SSVC record was updated as recently as October 16, so someone is on it. We'll update as soon as a patch or official advisory lands.

References: VulnCheck advisory https://www.vulncheck.com/advisories/archon-0.2.13-through-0.11.1-missing-authentication-via-api-control-api ; CVE record https://cvefeed.io/vuln/detail/CVE-2026-111322 ; researcher writeup https://hackmd.io/@hieuPenguinnn/archon-os-api-missing-authentication-default ; repo https://github.com/coleam00/Archon