plaincve:~$

// threat brief

CVE-2026-111322

Archon control API has no login by default: anyone on the network can drive the AI coding agent

CVSS
9.3 CRITICAL
CISA KEV
Not listed
Weakness
CWE-306
Topics
AI security

PlainCVE Team · Published 2026-10-20 · AI-assisted · Press brief ↓

AI review 2026-10-20 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

Archon 0.2.13–0.11.1 serves /api/* on 0.0.0.0 with no login by default; anyone reaching it controls the AI agent. Unfixed; 0.12.x (2026-10-17) kept defaults.

Who is affectedPeople running Archon 0.2.13 through 0.11.1 (inclusive) with web authentication off (the default) and the server port reachable from other hosts.
What happensAnyone who can reach the server port, with no account, can create and run workflows, inject messages into the AI agent's conversations, and approve or cancel the agent's pending actions. VulnCheck says this lets attackers run commands on the host as the Archon user; according to a news article (that page contains attack code, so this site does not link it), the original researcher says it is not remote code execution on the host. The sources disagree.
What to do nowThere is no official fix, and upgrading to 0.12.x does not change the defaults. Set HOST to 127.0.0.1 so only the local machine can connect, or firewall the /api/* API. For public deployments, Archon's SECURITY.md says to use the Caddy reverse proxy with authentication.
Affected versions0.2.13 through 0.11.1 (inclusive)
Fixed versionsNone (no official fix). The CVE record lists no fixed version; the release notes for v0.12.0 and v0.12.1 (2026-10-17) do not mention this issue, and the v0.12.1 code still binds to 0.0.0.0 by default with the /api/* gate off when web auth is off. The 'fixed' commit aa095446 listed by OSV is the v0.11.1 release commit (Release 0.11.1), not a fix.
CVSS vector
Show full vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Timeline
  • First public 2026-10-15

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check whether your version is in the affected range

    Run this on the host where you installed Archon from the git source, replacing /path/to/Archon with the source directory, to see the current release tag. The CVE record lists 0.2.13 through 0.11.1 (inclusive). Note: 0.12.0 and 0.12.1 (released 2026-10-17) are outside the CVE range but did not fix the issue; the v0.12.1 code still binds to 0.0.0.0 by default with the gate off when auth is off. Being on 0.12.x does not mean you are safe, so still do the two checks below.

    Read-only check
    git -C /path/to/Archon describe --tags
  2. 02Check whether the server listens on all interfaces

    Run this on the Linux host running Archon. It lists only the listening address for the default port 3090 (per the project's .env.example; use your port if you changed PORT). 0.0.0.0:3090 or *:3090 means other hosts may be able to reach it; 127.0.0.1:3090 means local only. macOS has no ss; on that host use lsof -nP -iTCP:3090 -sTCP:LISTEN instead.

    Read-only check
    ss -ltn 'sport = :3090'
    Step 1
  3. 03Check whether web authentication is on

    Per the project's code, auth turns on only when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set; ARCHON_WEB_AUTH_REQUIRED=false also turns the /api/* gate off. Run this on the host running Archon, in the directory of the .env your Archon actually uses. The command prints variable names and only the scheme of DATABASE_URL (so you can see whether it is postgresql), never passwords or secret values. PlainCVE's note: settings can also come from shell environment variables, systemd or docker-compose, and the v0.12.1 release notes say release binaries no longer load .env from their working directory, so no match here does not mean the setting is absent; check your actual startup configuration too.

    Read-only check
    grep -E '^(HOST|ARCHON_WEB_AUTH_REQUIRED)=' .env; grep -oE '^DATABASE_URL=[a-z]+:' .env; grep -oE '^BETTER_AUTH_SECRET=' .env
    Step 2
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Restrict the server to localhost

    The project's .env.example says HOST defaults to 0.0.0.0 and that setting it to 127.0.0.1 restricts the server to localhost.

    Step 1
  2. 02Firewall or segment access to /api/*

    A third-party threat feed recommends restricting network access to the /api/* control API until a fix is available.

    Step 1
  3. 03Turn on web authentication

    Per the project's code, auth turns on when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set, and the /api/* gate is then on by default; do not set ARCHON_WEB_AUTH_REQUIRED=false. Limitation (from the v0.12.1 api.ts and index.ts): the gate accepts the trusted proxy header X-Archon-User as identity, and with web auth on that header remains a fallback. The index.ts comment says the header is only sound when Archon is reachable solely through an authenticating reverse proxy that sets it (loopback bind); on a non-loopback bind anyone who can reach the port can forge it. So use an authenticating reverse proxy and bind to 127.0.0.1. PR #3147 separately notes that proxy deployments must explicitly strip the header or bind locally.

    Step 2
  4. 04Use an authenticating reverse proxy for public deployments

    Archon's SECURITY.md says: public deployments should use the Caddy reverse proxy with authentication (see deploy/docker-compose.yml).

    Step 1Step 2Step 3
RESPONDRespondIf you find signs of compromise
  1. 01Look for unexplained agent activity

    Our suggestion (we found no detection guidance from the project): if the server was exposed, look for workflows you did not create, unknown conversation messages, or approvals and cancellations you did not make, and check the repositories and files the agent can reach for unexpected changes.

    Step 3Step 4
  2. 02Track the patch status

    Per the project's GitHub releases, v0.12.0 and v0.12.1 were published on 2026-10-17, and neither release note mentions this CVE or any change to the binding or auth defaults; the v0.12.1 code still binds to 0.0.0.0 by default with the gate off when auth is off. There is no official fix. Keep the network restrictions above until the project announces one.

HARDENHardenPrevent the next one
  1. 01Don't rely on defaults to protect an AI agent

    Maintainer PR #3147 deliberately keeps open behaviour for solo and SQLite installs without authentication, so the network boundary is your responsibility.

    Step 1Step 2
  2. 02Limit what the agent and workflows can do

    Our analysis: how much a hijacked run can do probably depends on the workflows' and agent's permissions. Run it under a low-privilege account with only the access it needs.

    Step 4
Full remediation steps and notes

There is no official fix, so the priority is keeping other hosts away from the control API.

  • No fixed release. The CVE record lists no fixed version. The project’s GitHub releases show v0.12.0 and v0.12.1 published on 2026-10-17; neither release note mentions this CVE or any change to the binding or auth defaults. The v0.12.1 code still binds to 0.0.0.0 when HOST is unset, and the /api/* gate is only on when web auth is on. Upgrading to 0.12.x does not solve this.
  • OSV’s “fixed” entry is a mislabel. OSV’s auto-generated record lists a “fixed” git commit (aa095446…), but that commit is the 2026-09-25 “Release 0.11.1 (#3523)” release commit. It does not change authentication, the /api/* gate, or the default binding, and 0.11.1 itself is an affected version. Don’t assume an upgrade solves this based on the OSV record.
  • Order of changes. Restrict the network first (HOST set to 127.0.0.1, or a firewall), then adjust auth settings. Restart, then on that host use ss -ltn 'sport = :3090' (on macOS, lsof -nP -iTCP:3090 -sTCP:LISTEN) to confirm it no longer listens on 0.0.0.0.
  • When enabling auth. Per the project’s code, DATABASE_URL must be Postgres and BETTER_AUTH_SECRET must also be set; setting only one does not turn auth on.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

Archon control API has no login by default: anyone on the network can drive the AI coding agent: 1. Reaches the exposed Archon server port → 2. The /api/* auth gate lets the request through → 3. Drives the AI coding agent → 4. The agent acts within its workflows and permissionsCVE-2026-111322 · Archon control API has no login by default: anyone on the network candrive the AI coding agentAttackerYour systemReaches the exposed Archon server port — The control API binds to 0.0.0.0, meaning every network interface, by default, so hosts on the same network or even the internet may be able to reach it. 1Reaches theexposed Archonserver portThe /api/* auth gate lets the request through — Web authentication is off by default and only turns on when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set. A default install uses SQLite with no secret, so every request passes and no account is needed. 2The /api/* authgate lets therequest throughDrives the AI coding agent — The attacker can create and run workflows, inject conversation messages, and approve or cancel the agent's pending approvals. 3Drives the AIcoding agentThe agent acts within its workflows and permissions — VulnCheck says the agent runs with bypassPermissions and attackers can run commands on the host as the Archon user; a news article (that page contains attack code, so this site does not link it) quotes the researcher saying it is not remote code execution on the host. Our analysis: the real damage probably depends on what your workflows and agent are allowed to do, which no one has confirmed at runtime. 4The agent actswithin itsworkflows andpermissionsAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-111322-archon-api-missing-auth · CC BY 4.0
Archon control API has no login by default: anyone on the network can drive the AI coding agent: 1. Reaches the exposed Archon server port → 2. The /api/* auth gate lets the request through → 3. Drives the AI coding agent → 4. The agent acts within its workflows and permissionsCVE-2026-111322 · Archon control API hasno login by default: anyone on thenetwork can drive the AI coding agentReaches the exposed Archon server port — The control API binds to 0.0.0.0, meaning every network interface, by default, so hosts on the same network or even the internet may be able to reach it. 1AttackerReaches the exposed Archonserver portThe /api/* auth gate lets the request through — Web authentication is off by default and only turns on when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set. A default install uses SQLite with no secret, so every request passes and no account is needed. 2Your systemThe /api/* auth gate lets therequest throughDrives the AI coding agent — The attacker can create and run workflows, inject conversation messages, and approve or cancel the agent's pending approvals. 3AttackerDrives the AI coding agentThe agent acts within its workflows and permissions — VulnCheck says the agent runs with bypassPermissions and attackers can run commands on the host as the Archon user; a news article (that page contains attack code, so this site does not link it) quotes the researcher saying it is not remote code execution on the host. Our analysis: the real damage probably depends on what your workflows and agent are allowed to do, which no one has confirmed at runtime. 4Your systemThe agent acts within itsworkflows and permissionsAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-111322-archon-api-missing-auth
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Reaches the exposed Archon server port

    The control API binds to 0.0.0.0, meaning every network interface, by default, so hosts on the same network or even the internet may be able to reach it.

    Defense: Set HOST to 127.0.0.1 to allow local connections only, or use a firewall or network segmentation to limit who can reach /api/*.

  2. Your system

    The /api/* auth gate lets the request through

    Web authentication is off by default and only turns on when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set. A default install uses SQLite with no secret, so every request passes and no account is needed.

    Defense: Per the project's code, the gate is on by default once web auth is enabled; do not set ARCHON_WEB_AUTH_REQUIRED=false. Caveat (from the project's code): the gate accepts the trusted proxy header X-Archon-User as identity, and a code comment in index.ts says that header is only sound when Archon is reachable solely through an authenticating reverse proxy that sets it (loopback bind); on a non-loopback bind any client that can reach the port can forge it. So put it behind an authenticating reverse proxy and bind to 127.0.0.1. PR #3147 separately notes that proxy deployments must explicitly strip the header or bind locally (from PR #3147, not the code comment).

  3. Attacker

    Drives the AI coding agent

    The attacker can create and run workflows, inject conversation messages, and approve or cancel the agent's pending approvals.

    Defense: For public deployments, put it behind the Caddy reverse proxy with authentication (from Archon's SECURITY.md).

  4. Your system

    The agent acts within its workflows and permissions

    VulnCheck says the agent runs with bypassPermissions and attackers can run commands on the host as the Archon user; a news article (that page contains attack code, so this site does not link it) quotes the researcher saying it is not remote code execution on the host. Our analysis: the real damage probably depends on what your workflows and agent are allowed to do, which no one has confirmed at runtime.

    Defense: Run Archon under a low-privilege account and give workflows only the capabilities they need.

Who is affected

ConditionAffected?
Archon 0.2.13–0.11.1 + web auth off (default) + server port reachable from other hostsAffected
Same versions, but HOST set to 127.0.0.1Only the local machine can connect; other hosts can’t
Web auth enabled but ARCHON_WEB_AUTH_REQUIRED=false set/api/* gate is still off, so affected
Before 0.2.13Outside the range listed in the CVE
0.12.0, 0.12.1 (released 2026-10-17)Outside the range listed in the CVE, but not fixed: the v0.12.1 code still binds to 0.0.0.0 by default with the gate off when auth is off, so check it the same way as the rows above
A fixed releaseNone so far (see below)

“The researcher” here means the write-up by the finder, hieuPenguinnn (that page contains exploit code, so we don’t link to it). The researcher says this is a different flaw from CVE-2025-69443, which concerned the archived Python backend.

How it works

Archon is an AI coding agent tool. Its server offers a /api/* control API (an interface other programs use to send it commands over the network) for creating workflows, messaging the agent, and approving or cancelling the agent’s pending actions.

The problem comes from two defaults stacked together:

  1. It listens on every network interface. The control API binds to 0.0.0.0 by default, so other computers that can reach the host can connect, not just the local machine.
  2. Authentication is off by default. According to the project’s code at v0.11.1, web auth turns on only when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set. The researcher notes that a default install uses SQLite and sets no secret, so the auth gate passes every request without checking who sent it.

The result: anyone who can reach the server port can drive the AI agent without an account. This maps to CWE-306 (missing authentication for critical function). Maintainer PR #3147 explicitly states that solo and SQLite installs without authentication keep their current open behaviour, so this is to some degree a deliberate design.

The flawed approach (PlainCVE’s conceptual illustration, not the original code):

Show code example(ts)
// No auth configured → let every /api/* request through
if (!authConfigured) return next();

A safer approach (PlainCVE’s conceptual illustration, not an actual project fix):

Show code example(ts)
// No auth configured → accept only local connections; reject the rest
if (!authConfigured && !isLoopback(req)) return reject(401);

Sources disagree on how much damage is possible. VulnCheck says the agent runs with bypassPermissions and attackers can run commands on the host as the Archon user. A news article (that page contains attack code, so this site does not link it) quotes the original researcher saying it is not remote code execution on the host. Our analysis: what a hijacked run can do probably depends on what your workflows and agent are allowed to do, and no one has confirmed this in a live environment. The researcher only read the v0.11.1 source code and did not validate it at runtime.

Timeline

DateEvent
2026-09-02Maintainer PR #3147 opened (about conversation-ownership access control); it states that solo and SQLite installs without authentication keep the open behaviour. It does not mention the default 0.0.0.0 binding and does not treat it as this CVE’s issue. First disclosure stays 2026-10-15 (CVE record)
2026-09-25v0.11.1 released; the researcher reviewed the code at this tag
2026-10-15CVE reserved and published by VulnCheck
2026-10-16A news article (that page contains attack code, so this site does not link it) reports the latest release at that time is still 0.11.1, with no public fix or advisory
2026-10-17v0.12.0 and v0.12.1 released; the release notes do not mention this issue, and the default binding and auth gate are unchanged (per the releases page and the v0.12.1 code)
2026-10-18Still not listed in CISA KEV

Further reading

  • Scoring differences: VulnCheck (the CNA) gives CVSS 4.0 9.3 and CVSS 3.1 9.8, both Critical; the researcher’s own write-up rates it “high”. NVD’s analysis status is “Deferred”.
  • Who assigned it: VulnCheck assigned the CVE, not the Archon project. The GitHub Advisory Database lists it as GHSA-3q7p-hhhj-qh4p, but GitHub has not reviewed it.
  • Exploitation: Not in CISA KEV, and no evidence of exploitation in the wild or as a zero-day. CISA’s SSVC enrichment rates exploitation as “poc” (proof of concept), but a news article (that page contains attack code, so this site does not link it) says no public PoC existed as of October 16, and the researcher’s example requests were never run against a live instance. EPSS estimates about 0.69% (51.9th percentile).
  • We found no security advisory or fix from the project in the sources we reviewed, and the project issues, PRs and 0.12.x release notes we have seen do not mention this CVE.
  • Credit: hieuPenguinnn.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-20 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. CVE / NVD / OSVCVE-2026-111322 Record (CVE Services API) · CVE Program / VulnCheck (CNA), 2026-10-15 · accessed 2026-10-18
  2. CVE / NVD / OSVNVD - CVE-2026-111322 · NIST · accessed 2026-10-18
  3. AdvisoryArchon 0.2.13 through 0.11.1 Missing Authentication via /api/* Control API · VulnCheck · accessed 2026-10-18
  4. AdvisoryGitHub Advisory Database entry GHSA-3q7p-hhhj-qh4p (unreviewed) · GitHub · accessed 2026-10-18
  5. OtherOSV - CVE-2026-111322 · OSV · accessed 2026-10-18
  6. VendorArchon releases (GitHub) · coleam00/Archon (GitHub) · accessed 2026-10-18
  7. VendorArchon commit aa095446 (Release 0.11.1) · coleam00/Archon (GitHub) · accessed 2026-10-18
  8. VendorArchon server entry at v0.12.1 (packages/server/src/index.ts) · coleam00/Archon (GitHub) · accessed 2026-10-18
  9. VendorArchon API routes at v0.12.1 (packages/server/src/routes/api.ts) · coleam00/Archon (GitHub) · accessed 2026-10-20
  10. VendorArchon auth config at v0.12.1 (packages/server/src/auth/config.ts) · coleam00/Archon (GitHub) · accessed 2026-10-18
  11. VendorArchon .env.example at v0.11.1 · coleam00/Archon (GitHub) · accessed 2026-10-18
  12. VendorArchon auth config at v0.11.1 (packages/server/src/auth/config.ts) · coleam00/Archon (GitHub) · accessed 2026-10-18
  13. VendorArchon PR #3147 · coleam00/Archon (GitHub) · accessed 2026-10-18
  14. VendorArchon SECURITY.md at v0.11.1 · coleam00/Archon (GitHub) · accessed 2026-10-20
  15. OtherCVE-2026-111322: Missing Authentication for Critical Function in coleam00 Archon · OffSeq Radar · accessed 2026-10-18

Press brief

In one sentence

Archon is an open-source AI coding agent tool. In versions 0.2.13 through 0.11.1, its /api/* control API requires no login by default and listens on all network interfaces, so anyone who can reach the server can command the AI agent. The CVE was published on October 15, 2026, assigned by VulnCheck with a CVSS 4.0 score of 9.3. There is no official fix; the 0.12.0 and 0.12.1 releases of October 17 do not mention the issue and did not change the defaults. It is not in CISA's Known Exploited Vulnerabilities catalog, and there is no evidence of exploitation in the wild.

Key facts

Affected versions
0.2.13 through 0.11.1 (inclusive) cveawg.mitre.org
Severity
CVSS 4.0 9.3, CVSS 3.1 9.8 (VulnCheck, CNA) cveawg.mitre.org
Disclosed
2026-10-15 cveawg.mitre.org
Credit
hieuPenguinnn vulncheck.com
Patch status
No official fix; the release notes of the latest release, v0.12.1 (2026-10-17), do not mention this issue github.com
v0.12.1 defaults
The v0.12.1 code still binds to 0.0.0.0 when HOST is unset raw.githubusercontent.com
EPSS
About 0.69% (51.9th percentile) api.github.com

Confirmed

  • The /api/* control API in 0.2.13 through 0.11.1 lacks authentication and binds to 0.0.0.0 by default.
  • Per the project's code, web auth is off by default and only turns on when both a Postgres DATABASE_URL and a BETTER_AUTH_SECRET are set.
  • Not listed in CISA KEV as of 2026-10-18.
  • No official fix: the CVE record lists no fixed version; the commit aa095446 that OSV lists as fixed is the v0.11.1 release commit; the v0.12.1 code still binds to 0.0.0.0 by default with the /api/* gate off when auth is off.

Unconfirmed / disputed

  • Whether host commands can be run: VulnCheck says yes; a news article (that page contains attack code, so this site does not link it) quotes the researcher saying it is not remote code execution on the host.
  • Whether a public proof of concept exists: CISA's SSVC says 'poc'; a news article (that page contains attack code, so this site does not link it) says none existed as of October 16, and the researcher's examples were never run against a live instance.
  • The researcher only read the source code and did not validate at runtime; there is no evidence of exploitation in the wild.

Quotable line

When an AI agent's remote control is left on a public table by default, the risk isn't just the code; it's that anyone can press the buttons.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "Archon control API has no login by default: anyone on the network can drive the AI coding agent". PlainCVE. https://plaincve.date/en/vulns/cve-2026-111322-archon-api-missing-auth (accessed YYYY-MM-DD)
BibTeX
@misc{cve2026111322archonapimissingauth2026,
  title  = {Archon control API has no login by default: anyone on the network can drive the AI coding agent},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-111322-archon-api-missing-auth},
  note   = {Updated 2026-10-20}
}