Archon's Control API Listens on 0.0.0.0 With No Auth by Default, Raising Fresh Alarms for Agent Security

The open-source workflow engine Archon has been found to have a serious security design flaw: in its default installation, the /api/* endpoints used to control coding agents have neither authentication nor any binding restriction — they listen on 0.0.0.0. This means anyone on the same network can drive your agent, inject messages, or even click "Approve" on your behalf when the agent pauses.

The vulnerability was published by VulnCheck on October 15 as CVE-2026-111322, affecting Archon >= 0.2.13, <= 0.11.1. As of publication, the project's latest version is still v0.11.1, and no official fix has appeared on the GitHub security page.

Vulnerability Details: A High-Risk Control Plane With No Authentication

VulnCheck classifies the vulnerability as CWE-306, "Missing Authentication for Critical Function," with a CVSS 4.0 score of 9.3; the mirrored CVE record gives a CVSS 3.1 score of 9.8 (AV:N/AC:L/PR:N/UI:N). NVD's independent analysis is still in progress.

According to VulnCheck's description, the /api/* control API binds to 0.0.0.0 by default, and an attacker with network access can send messages to the coding agent, which "runs in bypassPermissions mode," allowing commands to be executed on the host as the Archon user. The finding was disclosed by security researcher hieuPenguinnn.

What the CVSS Scores and CWE Classification Mean

CWE-306 (Missing Authentication for Critical Function) refers to a system exposing a critical function without requiring the caller to prove their identity — a design-level flaw rather than an implementation-level coding error. The CVSS 4.0 score of 9.3 and the CVSS 3.1 score of 9.8 both fall into the "Critical" range. In the vector, AV:N means remotely exploitable, AC:L means low attack complexity, PR:N means no privileges required, and UI:N means no user interaction — a combination with zero barriers on all four axes means anyone who can reach the port can launch an attack. The discrepancy between the two version scores stems from CVSS 4.0 introducing supplementary assessment dimensions for downstream system impact, not from any change in the vulnerability itself. It's worth noting that a CVE ID merely indicates registration; NVD's independent analysis is not yet complete, meaning the official review conclusion may still change.

Why the Default Installation Is Wide Open

The root of the problem lies in three places in the code. The server decides its bind address in index.ts:

const hostname = process.env.HOST || '0.0.0.0';

The project's bundled .env.example documents this default and its escape hatch — "set to 127.0.0.1 to restrict to local access only." The default port is 3090.

Authentication is opt-in. The header of auth/config.ts states that web auth is disabled by default and only enabled when "Postgres's DATABASE_URL and BETTER_AUTH_SECRET are both present." The gate itself is a single line of code:

return isWebAuthEnabled(env)
  && env.ARCHON_WEB_AUTH_REQUIRED !== 'false';

When that function returns false, the middleware in routes/api.ts passes requests straight through. The researcher describes an out-of-the-box installation as SQLite plus no secret key, landing squarely on that open path. A stock installation will respond to /api/* without credentials from any machine that can reach port 3090.

The Essential Difference Between 0.0.0.0 and Opt-In Authentication

In TCP socket programming, binding to 127.0.0.1 means accepting connections only from the local loopback interface, whereas binding to 0.0.0.0 means listening on all network interfaces on the host — including the LAN NIC, VPN virtual adapters, and in some configurations even public addresses. Developers often don't notice the difference during local debugging, but once the machine joins a café Wi-Fi network, an office subnet, or a cloud provider's default VPC, the port becomes visible to the entire subnet. "Opt-in authentication" means authentication is off by default and must be explicitly enabled by the user supplying environment variables — the exact opposite of the secure-by-default principle of "on by default, can be turned off." Any deployment where someone forgets to configure it is left wide open.

What an Attacker Can Do, and What's Uncertain

In a default installation with no credentials, any client that can reach port 3090 can: start workflow runs, create sessions and inject messages the agent treats as operator input, approve or reject actions the agent has paused on, and connect or disconnect provider keys configured per user. The named routes involved include POST /api/workflows/<name>/run, POST /api/conversations/<id>/message, and POST /api/workflows/runs/<runId>/approve.

However, the researcher explicitly states: "This is not remote code execution on the host." They also note that "no runtime verification was performed" and that the example requests were "not executed against a live instance."

VulnCheck's advisory goes further, linking the flaw to command execution under the agent's bypassPermissions mode. Claude Code's permission mode documentation describes bypassPermissions as a mode where "everything" runs without asking, recommending it only for "isolated containers and VMs," and warning that it "offers no protection against prompt injection or accidental actions." How severe a hijacked run is depends on what your workflow and agent are allowed to do.

As of publication, there is no public exploit code. Public write-ups already lay out most of the attack recipe, and waiting for a PoC to drop is not a wise move.

Why bypassPermissions Mode Is Dangerous

Coding agents typically request user approval before performing sensitive operations like file writes and command invocations, and bypassPermissions skips the entire confirmation step, letting all tool calls execute directly. By design, this mode is only suitable for isolated containers or disposable VMs, where the blast radius is contained by the sandbox. But when the agent runs on a developer's host machine — holding SSH keys, cloud credentials, and repository write access — skipping confirmation is equivalent to handing a shell to anyone who can send a message to the control API. Combined with prompt injection, an attacker doesn't even need to call the API directly; they just need the agent to "incidentally" execute instructions while reading a malicious file.

Mitigations Before a Fix

Step one: bind to loopback. First set the project's documented variable in .env, then restart archon serve:

HOST=127.0.0.1

Check the current listening state:

lsof -nP -iTCP:3090 -sTCP:LISTEN

If the address shows *:3090 or 0.0.0.0:3090, all interfaces are listening; 127.0.0.1:3090 means loopback only. In Docker, the restriction should happen at publish time: docker run -p 127.0.0.1:3090:3090 <your-archon-image>.

Step two: turn on the auth gate. You need both a Postgres URL and a signing secret of at least 32 characters:

DATABASE_URL=postgresql://archon:CHANGE_ME@localhost:5432/archon
BETTER_AUTH_SECRET=<output of openssl rand -base64 32>

Unless you genuinely have an authenticating proxy in front, do not set ARCHON_WEB_AUTH_REQUIRED=false.

Step three: put an authenticated reverse proxy in front of shared deployments. The project's SECURITY.md already advises: "When deploying the server publicly, use a Caddy reverse proxy with authentication." A connectivity test against /api/health from another machine verifies whether the binding took effect.

Agent Runtime Frameworks Are Turning Into Servers

The fix the researcher recommends is not complicated: bind to 127.0.0.1 by default, require a local token for mutating routes even when web auth is off, and emit a warning at startup when binding to a non-loopback address without authentication. That's the same advice you'd give for any dashboard — except this dashboard sits in front of an agent with a shell, your provider keys, and an approve button.

This is also not the first time Archon has been hit with an unauthenticated backend issue. Previously, OX Security disclosed CVE-2025-69443 in the earlier Archon OS product line (0.1.0 to 0.3.11), where a backend port with "no CORS protection and no authentication" could be reached by a malicious web page. According to OX, the maintainers' position at the time was that the app was designed to run locally.

The gap between "it runs on my laptop" and "it's safe on a network" is exactly these engineering details: bind address, off-by-default authentication, and a fronting proxy. For any agent tool running a local HTTP service, users would do well to ask: what address is it bound to?

Why Local Dev Tools Keep Falling Into the Same Trap

Traditionally, developer tools were treated as "personal software," with a security model assuming the user is the sole operator — hence the many projects that focus on features without authentication. But once these tools start offering HTTP APIs, web UIs, plugin ecosystems, and long-running processes, they have effectively become servers while often retaining the default configuration of personal software: listening on all interfaces, no credentials, no CORS restrictions. Archon, the earlier Archon OS vulnerability, and similar issues in Jupyter, Ollama, and various DevContainer gateways all point to the same structural mismatch: developers' mental model is still "it only runs on my machine," while the network stack has long since exposed the port to the entire subnet.