Archon控制API默认无鉴权监听0.0.0.0，Agent安全再敲警钟

开源工作流引擎Archon被曝出一个严重的安全设计缺陷：在其默认安装下，用于控制编码Agent的/api/*接口既没有身份验证，又绑定在0.0.0.0上。这意味着同一网络中的任何人都可以驱动你的Agent、注入消息，甚至替你在Agent暂停时点击"批准"。

该漏洞由VulnCheck于10月15日发布为CVE-2026-111322，影响Archon >= 0.2.13, <= 0.11.1。截至发稿，项目最新版本仍停留在v0.11.1，GitHub安全页面尚未列出任何官方修复公告。

漏洞细节：缺失鉴权的高危控制面

VulnCheck将该漏洞归类为CWE-306"关键功能缺失身份验证"，CVSS 4.0评分9.3；同步镜像的CVE记录给出CVSS 3.1评分9.8（AV:N/AC:L/PR:N/UI:N），NVD的独立分析仍在进行中。

据VulnCheck的描述，/api/*控制API默认绑定到0.0.0.0，具备网络访问能力的攻击者可以向编码Agent发送消息，而该Agent"以bypassPermissions模式运行"，从而能够在主机上以Archon用户身份执行命令。该发现由安全研究员hieuPenguinnn公开。

CVSS 评分与 CWE 分类的含义

CWE-306（Missing Authentication for Critical Function）指的是系统在暴露关键功能时未要求调用方证明身份，属于设计层面的缺陷而非实现层的编码错误。CVSS 4.0 给出的 9.3 分与 CVSS 3.1 的 9.8 分都落入"严重"区间，向量中的 AV:N 表示可远程利用、AC:L 表示攻击复杂度低、PR:N 表示无需任何权限、UI:N 表示无需用户交互——四项全无门槛的组合意味着只要能连上端口就能发起攻击。两个版本分数存在差异，源于 CVSS 4.0 引入了对后续系统影响的补充评估维度，而非漏洞本身发生变化。需要注意的是，CVE 编号本身只表示已登记，NVD 的独立分析尚未完成，意味着官方复核结论仍可能调整。

为什么默认安装是敞开的

问题根源藏在三处代码里。服务器在index.ts中决定绑定地址：

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

项目自带的.env.example记录了这个默认值及其逃生舱——"设置为127.0.0.1可仅限本机访问"。默认端口为3090。

鉴权是opt-in的。auth/config.ts的文件头写明Web鉴权默认关闭，仅当"Postgres的DATABASE_URL和BETTER_AUTH_SECRET同时存在"时才启用。门控本身只是一行代码：

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

当该函数返回false时，routes/api.ts中的中间件直接放行请求。研究员将开箱即用的安装描述为SQLite加无密钥，恰好落入了这条敞开路径。一个原装安装会从任何能访问3090端口的机器上无凭证响应/api/*。

0.0.0.0 与 opt-in 鉴权的本质区别

在 TCP 套接字编程中，绑定 127.0.0.1 意味着只接受来自本机回环接口的连接，而绑定 0.0.0.0 表示监听主机上所有网络接口，包括局域网网卡、VPN 虚拟网卡乃至某些配置下的公网地址。开发者在本地调试时往往感知不到差别，但一旦同一台机器接入了咖啡厅 Wi-Fi、办公网段或云厂商的默认 VPC，端口就会对整个网段可见。"opt-in 鉴权"则是指默认状态下身份验证处于关闭，必须由使用者主动提供环境变量才能开启——这与"默认开启、可主动关闭"的 secure-by-default 原则正好相反，任何忘记配置的部署都会裸奔。

攻击者能做什么，以及存疑的部分

在默认安装且无凭证的情况下，任何能访问3090端口的客户端都可以：启动工作流运行、创建会话并注入Agent视作操作者输入的消息、批准或拒绝Agent暂停的动作，以及在按用户配置提供商密钥时连接或断开它们。涉及的具名路由包括POST /api/workflows/<name>/run、POST /api/conversations/<id>/message和POST /api/workflows/runs/<runId>/approve。

不过，研究员本人明确表示："这不是主机上的远程代码执行。"他们同时声明"未进行运行时验证"，示例请求"未针对实际运行的实例执行"。

VulnCheck的公告则更进一步，将该缺陷与Agent的bypassPermissions模式下的命令执行关联起来。Claude Code的权限模式文档将bypassPermissions描述为"一切"都无需询问即可运行的模式，仅推荐用于"隔离的容器和虚拟机"，并警告它"对提示词注入或意外操作不提供任何防护"。一次被劫持的运行有多严重，取决于你的工作流和Agent被允许做什么。

截至发稿，尚无公开的利用代码。公开的写up中已经列出了大半个攻击配方，等待PoC发布并非明智之举。

bypassPermissions 模式为何危险

编码 Agent 通常在执行文件写入、命令调用等敏感操作前会请求用户批准，而 bypassPermissions 会跳过整个确认环节，让所有工具调用直接执行。该模式在设计上只适用于隔离的容器或一次性虚拟机，因为这些环境的破坏半径被沙箱限制。但当 Agent 运行在开发者的宿主机上（持有 SSH 密钥、云凭证、代码仓库写权限），跳过确认就等于把 shell 交给了任何能向控制 API 发消息的人。配合提示词注入，攻击者甚至不需要直接调用接口，只需让 Agent 在读取一个恶意文件时"顺带"执行指令。

修复前的缓解措施

第一步：绑定回环地址。 先在.env中设置项目已文档化的变量，然后重启archon serve：

HOST=127.0.0.1

检查当前监听状态：

lsof -nP -iTCP:3090 -sTCP:LISTEN

地址显示为*:3090或0.0.0.0:3090意味着所有接口都在监听，127.0.0.1:3090则仅限回环。Docker场景下限制应在发布时进行：docker run -p 127.0.0.1:3090:3090 <your-archon-image>。

第二步：开启鉴权门。 需要同时配置Postgres URL和至少32字符的签名密钥：

DATABASE_URL=postgresql://archon:CHANGE_ME@localhost:5432/archon
BETTER_AUTH_SECRET=<openssl rand -base64 32 的输出>

除非确有认证代理在最前面，否则不要设置ARCHON_WEB_AUTH_REQUIRED=false。

第三步：在共享部署前放置带认证的反向代理。 项目SECURITY.md已建议："公开部署服务器时，请使用带认证的Caddy反向代理。"从另一台机器用/api/health做连通性测试即可验证绑定是否生效。

Agent运行框架正在变成服务器

研究员建议的修复并不复杂：默认绑定127.0.0.1，即使在Web鉴权关闭时也对变更类路由要求本地令牌，在非回环绑定且无鉴权时于启动阶段发出警告。这和对任何仪表盘的建议一样——只是这个仪表盘背后站着一个拥有shell、你的提供商密钥和一个批准按钮的Agent。

这也不是Archon第一次被曝出未鉴权后端问题。此前OX Security曾披露过较早的Archon OS产品线（0.1.0至0.3.11）中CVE-2025-69443，一个"没有CORS保护也没有身份验证"的后端端口可被恶意网页访问。按OX的说法，维护者当时的立场是该应用设计为本地运行。

从"在我笔记本上能跑"到"在网络上安全"，中间的差距恰恰是绑定地址、默认关闭的鉴权和前置代理这些工程细节。对于所有运行本地HTTP服务的Agent工具，用户都值得问一句：它绑在哪个地址上？

本地开发工具为何普遍踩同一个坑

传统上，开发者工具被视为"个人软件"，安全模型假设使用者就是唯一操作者，因此大量项目只做功能不做鉴权。但当这些工具开始提供 HTTP API、Web 界面、插件生态和常驻进程时，它们实际上已经变成了服务器，却往往保留了个人软件的默认配置——监听所有接口、无凭证、无 CORS 限制。Archon 与早些时候的 Archon OS 漏洞，以及 Jupyter、Ollama、各种 DevContainer 网关的同类问题，都指向同一个结构性错配：开发者的心智模型还停留在"它只跑在我的机器上"，而网络栈早已把端口暴露给了整个网段。