Marico's space
最近折腾 Archon 这个开源工作流引擎（就是驱动 Claude Code、Codex、Pi 这些 AI 编程工具的后端），结果发现一个挺离谱的漏洞：CVE-2026-111322。简单说就是它的控制 API 默认没有任何认证，而且监听在所有网络接口上。这篇把问题说清楚，顺便给出一套临时加固方案，不需要改代码，10 分钟搞定。
2026 年 10 月 15 日，VulnCheck 公布了这个漏洞。问题说白了就三句话：默认安装时，Archon 的 /api/* 控制接口没有登录验证，服务绑定到 0.0.0.0（即所有网卡），端口默认是 3090。任何能访问到你机器 309 端口的人，都能驱动你的 AI 编程助手。
Archon（GitHub 上 23000+ 星）是一个开源引擎，通过 YAML 定义的工作流来驱动 AI 编程工具。跑 archon serve 之后，Web 控制台可以观察 agent 工作、给它发消息、审批它暂停等待人工确认的操作。这个控制台背后就是本次 CVE 涉及的 HTTP 控制 API。
安全研究员 hieuPenguinnn 通过代码审计（审查版本为 v0.11.1，发布于 2026-09-25），定位到了三个问题：
packages/server/src/index.ts 里 bind host 设置为 process.env.HOST || '0.0.0.0'，附带的 .env.example 也确认了默认端口是 3090。默认安装的话，3090 端口可以从网络直接访问。/api/* 的中间件只有在 isApiGateEnabled() 返回 true 时才会校验身份，而这个函数要求同时满足两个条件：有 Postgres DATABASE_URL 并且 有 BETTER_AUTH_SECRET。默认安装用 SQLite，两个都不设置，所以所有请求都直接放行。POST /api/workflows/{name}/run）、向对话注入消息、审批/拒绝 agent 暂停的操作、连接/断开供应商密钥。一句话版本：任何能访问你机器 3090 端口的人，都能操控你的 AI 编程助手。这个 CVE 评级为 CWE-306（关键功能缺少认证）+ CWE-862，CVSS 9.8（v3.1）/ 9.3（v4.0）。受影响版本：0.2.13 到 0.11.1。截至 2026 年 10 月 16 日，最新版本仍然是 v0.11.1，官方还没有发布补丁和安全公告。
有一点要说明：研究者通过代码审计没有直接证明从外部能实现远程代码执行——供应商密钥列表接口只返回元数据，实际能造成的损害取决于配置的 workflow 和 agent 能力。但 VulnCheck 给了 9.8 分，因为控制平面确实可以被网络访问，而 agent 本身是可以执行命令的。不管怎么界定，当成严重漏洞处理就对了。
agent 跑在你的机器上，用的是你的权限。它的控制面不应该暴露在网络上。
.env 文件（或你设置环境变量的方式）术语说明： <your-host> 指运行 Archon 的机器。端口 3090 是 .env.example 里的默认值，如果你改过就替换掉。
先确认 Archon 版本。如果在 0.2.13 到 0.11.1 之间（含），就是受影响的版本：
# inside your Archon checkout or container
git describe --tags 2>/dev/null || grep -m1 '"version"' package.json
然后检查配置。当以下三个条件同时满足时，你就暴露了：没有把 HOST 设为 127.0.0.1、没有 Postgres DATABASE_URL、没有 BETTER_AUTH_SECRET：
grep -E '^(HOST|PORT|DATABASE_URL|BETTER_AUTH_SECRET)' .env
如果相关行缺失，说明走了默认值：HOST=0.0.0.0、SQLite、无认证。这就是那个有漏洞的状态——而且是官方打包时的默认配置。（注意：这跟 CVE-2025-69443 不是一回事，那个是 Archon 归档的 Python 后端的问题。）
别光看配置文件，直接查监听端口：
ss -tlnp | grep 3090
应该只看到一行。如果显示 0.0.0.0:3090，控制 API 整个网络都能访问。如果显示 127.0.0.1:3090，网络可达性已经堵住了，可以直接跳到第六步。
警告： URL 里写
localhost不代表服务只在本地回环。很多场景下流量通过隧道代理进来，但底层服务仍然绑定在0.0.0.0。ss的输出才是最终答案。
这是单次改动收益最高的修复。.env.example 里其实已经写明白了：
# HOST=0.0.0.0 # Bind address (default: 0.0.0.0). Set to 127.0.0.1 to restrict to localhost only.
# PORT=3090 # Default: 3090.
在 .env 里设置（没有就新建一个）：
HOST=127.0.0.1
重启服务，然后重跑第二步。应该能看到 127.0.0.1:3090 了——网络上的其他主机再也访问不到这个 API，哪怕认证门还是关着的。研究者确认这个改动彻底去除了网络可达性。
绑定配置是一层，防火墙是第二层。除了本地机器，拒绝所有到 3090 的入站流量：
# Ubuntu/Debian with ufw
sudo ufw deny 3090
ufw deny 3090 会阻止所有网卡上该端口的入站连接。本机回环流量不受影响，Web 控制台本地访问正常。如果你用 Docker 暴露了端口，把 -p 3090:3090 映射去掉，改用 --network host 或容器间网络——暴露的端口会把绑定配置刚堵上的门又打开。
只有当你真的需要从其他机器访问 Archon 时才做这一步。官方启用认证的方式是同时设置 Postgres 数据库 URL 和密钥：
DATABASE_URL=postgresql://<user>:<password>@<host>:5432/archon
BETTER_AUTH_SECRET=<generate-a-long-random-string>
密钥用 openssl rand -hex 32 生成——不要从其他服务复用。两个都设置好之后，isApiGateEnabled() 返回 true，中间件会在非白名单的 /api/* 路由上返回 401。如果现在迁移成本太高，先保持第三步和第四步的改动，在 Archon 前面加个带 Basic 认证的反向代理。永远不要把 3090 端口直接暴露到公网或不可信网络。
按顺序做三个检查：
# 1. 本地回环仍然正常响应
curl -s http://127.0.0.1:3090/api/health # 2. 外部网卡没有监听
ss -tlnp | grep 3090 # expect 127.0.0.1:3090 only # 3. Web 控制台本地能正常加载
# open http://127.0.0.1:3090 in your browser
如果检查 1 通过、2 只显示回环那一行，修复就到位了：agent 控制平面只能从本机访问，其他地方一律不通。
修复只需要三行配置加一条防火墙规则——不是补丁，因为官方还没出。
大概率安全——前提是网络上没有其他设备能访问它。"大概率"不是真正的安全控制，还是跑一下第二步，确认看到 127.0.0.1:3090。咖啡店 Wi-Fi 和办公室局域网恰恰是 0.0.0.0 绑定最危险的地方。
不是。CVE-2025-69443 是 Archon 归档的 Python 后端的问题。CVE-2026-111322 在 TypeScript Archon OS 服务端——两个不同的代码库，两个不同的问题。
还没有。2026 年 10 月 16 日为止，这个漏洞没有公开安全公告，最新版本（9 月 25 日发布的 v0.11.1）仍然受影响。关注 coleam00/Archon releases 页面，等待有版本说明改了默认绑定或加了认证——在那之前保持上面的临时加固。
不会——这是 Archon 特有的问题。但这个模式值得全面排查：你跑的任何 agent 工具（archon serve、本地 LLM 服务、MCP 服务器）如果默认绑定 0.0.0.0，那就是同类问题。ss -tlnp 查一下在跑的服务，对每个 0.0.0.0 都打个问号。
我没有实际搭起 Archon 来对着真实实例发请求验证——上面的发现来自 VulnCheck 的公告（2026 年 10 月 15 日）和研究者在 v0.11.1 的代码审计，两者对三个根因的结论一致。加固步骤都是配置层面的，风险很低，但动手之前还是先备份一下 .env。另外，这个加固解决的是网络可达性问题，对提示词注入、恶意插件、供应链攻击这些 agent 自身的安全问题没有帮助——那些是另外的问题，有各自的应对方式。
/api/* 控制 API 没有登录验证，默认绑定到 0.0.0.0:3090。DATABASE_URL 和 BETTER_AUTH_SECRET 时才会启用，默认 SQLite 安装两个都不设。HOST=127.0.0.1 并用防火墙封堵 3090 端口——两处改动彻底去掉网络可达性，用 ss -tlnp 验证。0.0.0.0 的本地服务都是这个漏洞的同类变体，等着被分配 CVE 编号。下一步：如果你的团队在用 AI 编程助手，可以看看 Plugin4Shell 的分析——另一个零点击漏洞，问题的起因是一个固定的插件 commit 其实是伪造的。如果你自己托管 n8n，还有一篇关于暴露实例加固清单的文章，讲的是同一类"绑定-暴露"模式在自动化基础设施上的问题。