OpenCode 的 MCP 登入流程將伺服器的 URL 交給了 PowerShell——而且沒有任何 CVE 可標示此事。

在 2026 年 10 月 19 日，Pillar Security 揭露了OpenCode 中的遠端程式碼執行漏洞；這是由 Anomaly 維護的開源程式碼編寫代理：一個遠端 Model Context Protocol 伺服器，若開發者曾加以設定，便可在 MCP OAuth 登入期間於該開發者自己的機器上執行任意程式碼，中間沒有任何同意提示。該漏洞僅限於 Windows 與 Windows Subsystem for Linux；在這些環境中，OpenCode 會將伺服器提供的登入 URL 交給 PowerShell 命令，而未對其進行轉義。Pillar 將受影響範圍定為 1.0.137 至 1.18.32。Anomaly 在 1.18.33 中修復，於 2026 年 9 月 28 日 發布至 npm，且未申請 CVE、也未發布公告——因此一般漏洞情報來源不會告訴受影響團隊要升級。Pillar 報告沒有證據顯示該漏洞曾被用於攻擊。這是 AI 事件檔案中的一筆紀錄，每筆紀錄都附有自己的來源、嚴重程度、信心等級與爭議旗標。

那個缺陷實際上究竟是什麼

當 MCP 用戶端連線到想要授權的遠端伺服器時，它會執行 OAuth 探索握手。伺服器會以 401 和指向其探索文件的挑戰作為回應，而那些文件中的一個欄位——authorization_endpoint——會告訴用戶端要將使用者送至何處登入。它是一個自由格式字串，而被驗證的一方就是選擇它的一方。

在 OpenCode 1.18.32 中，該字串從網路傳輸一路進到了殼層。Pillar 追蹤了這條路徑：從伺服器的探索文件出發，經過 MCP SDK 進入 oauth-provider.ts、mcp/index.ts 與 browser.ts，最後抵達 open——OpenCode 用來啟動瀏覽器的小型套件。這條路徑上沒有任何環節檢查該 URL 的 scheme，也沒有任何環節將其與開發者所設定伺服器的 origin 進行比對。依設計，握手是自動的——重點正是把你送到登入頁面，而不必讓你複製 URL——因此，伺服器的回應與啟動器之間沒有任何核准步驟。

The launcher is where it broke. On macOS and Linux, open passes the address as an argument vector and no shell is involved. On Windows, version 10.1.2 of open — the version every affected OpenCode release pinned — builds a PowerShell command, base64-encodes it and runs it with powershell -EncodedCommand. Pillar quotes the source: the application name is escaped on one line, and the target URL is not. PowerShell evaluates $(...) subexpressions inside double-quoted strings, so an address of the form https://evil.test/$([IO.File]::WriteAllText('C:\Users\Public\pwned.txt','RCE')) runs before the browser launch fails. OpenCode discards that failure.

有兩個特性讓它容易被忽略。酬載中不含空格，因此 URL 正規化會讓它原封不動，而且它在語法上就是一個普通的 https 位址。此外，伺服器在設定當時未必帶有惡意：Pillar 指出，日後遭入侵、註冊表項目被劫持、網域搶註或網域過期，每一種情況都會把原本受信任的設定項目變成散布機制。

誰被曝光了

暴露族群是使用 Windows 與 WSL、執行 OpenCode 並已設定遠端 MCP 伺服器的使用者。Pillar 形容 OpenCode 大約有 每週 300 萬次 npm 下載以及 21.1 萬個 GitHub 星號；《Infosecurity Magazine》的報導則指星號數超過 21.8 萬。這兩個數字都不是受影響安裝數的統計，而且目前沒有人公布過這樣的數字。

觸發點是兩個主要說法唯一分歧之處，而這對風險與嚴重程度都很重要。Pillar 將漏洞利用描述為不需要額外的使用者互動或同意。The Hacker News 在其 10 月 22 日的報導中表示，瀏覽器步驟只有在開發者開始登入時才會執行——透過執行opencode mcp auth或發出對應的請求——而僅將伺服器設定好，或開啟工作階段，並不會觸及該步驟。無論哪種情況，開發者都沒有做任何不尋常的事；對已在設定中的伺服器啟動驗證是例行操作。但「無互動」和「一次例行互動」是不同的說法，而這項差異會直接影響評分。

這項修正送達時，被描述為一次重構。

Pillar 透過 GitHub Security Advisory 私下回報了該漏洞，時間為 2026 年 8 月 29 日，並附上完整重現素材。於 9 月 25 日，其在該安全公告討論串之外後續追蹤；Anomaly 確認該回報已送達其團隊，並回覆表示惡意 MCP 伺服器不在其威脅模型範圍內。同日，pull request #51414——以 commit 29f07e0c 合併——正式落地。其被描述為將八個瀏覽器啟動呼叫點整合成單一輔助函式。版本 1.18.33 於三天後的 9 月 28 日登上 npm。

這個修補程式有三層。open 相依套件已移至 11.0.4，它會將目標以單引號包住，而 PowerShell 不會展開單引號內的任何內容。一個新的 openUrl() 輔助函式會拒絕非 HTTP(S) 配置。一項配置檢查已加入 redirectToAuthorization 本身，也就是 Pillar 在其報告中所指出的邊界。無論是提取要求還是發行說明，都沒有提到安全漏洞，而 Anomaly 也未要求 CVE。

《Hacker News》報導指出，Anomaly 公布的安全政策聲明，使用者自行設定的 MCP 伺服器「在我們的信任邊界之外」，而且該公司今年已針對其他 OpenCode 程式碼執行漏洞發布公告，其中包括一個在八月修補的漏洞。Pillar 對其收到回覆的描述更為直白：「我們已更新了相依套件，但一般而言，試圖應對惡意的 MCP 伺服器並不在我們的威脅模型範圍內。」

若按時間順序來看，這條時間線把 OpenCode 的錯誤放在一條五年軌跡的終點，而不是起點。造成它的缺陷早已公開，而其修正也早已發布，甚至在寫下使用它的那行程式碼之前就已如此。

為什麼方案驗證無法阻止它

對於這類錯誤，公認的補救措施是 URL scheme 驗證：封鎖奇怪的 scheme，允許 http 與 https，到此為止。這是 MCP TypeScript SDK 隨附的做法，也是 OpenCode 在 1.18.33 加入的做法。Pillar 的 payload 通過了上述每一項檢查，因為它是 https。SDK 的拒絕清單會封鎖 javascript:、data:與vbscript:；更嚴格的 http/https 允許清單曾於 2025 年 8 月在 SDK pull request #841 中提出，但未合併即關閉，而 pull request #877 在 v1.17.4 中推出了三種 scheme 的拒絕清單——而 Pillar 表示，在其發布時，SDK 1.32.0 仍採用該政策。真正堵住 OpenCode 漏洞的是依賴版本升級，而不是那些看似安全修補的檢查。

歷史顯示，不應將此事視為單一專案的疏失。open 套件自 2021 年起就在 README 中警告，它不提供任何安全保證，清理輸入是呼叫端的責任。2020 年 10 月，一名使用者提交 issue #202，回報在 WSL 2 上，含有美元符號的 URL 會遺失自身的一部分——也就是字串展開——當時僅以連結損壞的惱人問題提報。2023 年 10 月，一名 Adobe 工程師提交 issue #323「在 Windows 上開啟 URL 時的作業系統命令注入」，附上一行概念驗證：open('https://$(calc.exe)')。維護者引用 README，並表示歡迎提出改善轉義的 pull request；該 issue 在 open 11.0.0 仍於 2025 年 11 月 15 日發布轉義修正的三天前，被以「不打算處理」關閉。OpenCode 於 2025 年 12 月 7 日寫下其瀏覽器啟動呼叫，當時距離 open 的修正版本問世已過三週，而其所依據的版本鎖定早已是數個月前的舊版。

在那則呼叫被寫下之前的幾個月裡，MCP 生態系統記錄了三起 CVE，皆涉及同一個 sink 或同一個欄位：CVE-2025-6514 存在於 mcp-remote（CVSS 9.6，由 JFrog 於 2025 年 7 月 9 日揭露）、CVE-2025-58062 存在於 openmcp-client，以及 CVE-2025-10619 存在於 sequa-mcp。Pillar 對比的是那些完全不會用遠端字串建構 shell 指令的用戶端：它點名 gemini-cli、Claude Code、github-mcp-server 與 Docker 的 mcp-gateway 是將 URL 作為引數向量傳遞，這讓「字串裡究竟包含什麼」不再是關鍵所在。

什麼是已確立的，什麼不是

這份紀錄被檔案館評為信心等級 A，而其背後的報導也站得住腳。Infosecurity Magazine 於 10 月 20 日刊出自身對 Pillar 的 Eilon Cohen 的訪談；The Hacker News 於 10 月 22 日刊出自身的報導；丹麥國家 CERT（DKCERT）於 10 月 21 日引用 Infosecurity 概述了這項發現；雲端安全聯盟（Cloud Security Alliance）的研究實驗室則發表了一份分析，補充了下方唯一一項實質性的但書。這些都不是最初報導此事的媒體，但它們對機制、版本及靜默修復的說法一致。Anomaly 本身則未發布任何關於該漏洞的內容。

已確立，並記錄在案：

• 該缺陷、其機制及其平台影響範圍。Pillar 指出了具體的原始碼行，而修正可在公開的 1.18.32 到 1.18.33 diff 中看見；兩篇獨立的新聞報導描述了相同的資料流。

• 受影響的範圍為 {{1}}1.0.137{{/1}} 至 {{2}}1.18.32{{/2}}，以及已修復的版本 {{3}}1.18.33{{/3}}，於 {{4}}2026 年 9 月 28 日{{/4}} 發布。

• 目前不存在任何 CVE，也不存在任何安全公告。這點可以查證，而且對防禦者而言是關鍵的支撐事實。

• 目前尚未有任何漏洞遭利用的報告。Pillar 表示，並未發現該漏洞在攻擊中被使用的任何跡象，而《The Hacker News》指出，並未公布任何入侵指標（indicators of compromise）。未公布入侵指標並不代表其不存在，且在缺乏廠商遙測資料的情況下，這兩種解讀都無法獲得證實。

尚未確立，或存在矛盾：

• 9.8。這個數字是 Pillar 提出的 CVSS v3.1 分數，並非官方分數：由於沒有 CVE，就沒有 NVD 分數，也沒有廠商分數。Cloud Security Alliance 的研究備註指出，9.8 假設不需使用者互動；而如果 The Hacker News 對觸發條件的描述正確，那麼需要使用者互動的評級——約 8.8——會更合適。本文並未對此下定論；檔案庫自身的高嚴重性標籤是一種分類，而非分數。

• 發布日期。Pillar 的報告在頁首註明日期為 2026 年 10 月 19 日，兩則新聞報導也都採用該日期；Pillar 自己報告底部的揭露時程則將發布日期列為 10 月 4 日。檔案庫記錄為 10 月 19 日，精確至日。

• 受影響族群的規模。目前尚未公布任何數量。上述的下載數與星號數是儲存庫指標，並非安裝次數。

• 是否真的有機器遭到入侵。已公開的資料沒有任何內容支持這點，而紀錄中也沒有顯示任何實際損害。

有什麼改變，以及該怎麼做

補救方式是進行版本檢查，因為沒有其他辦法能提醒你。OpenCode 1.18.33 或更新版本已修復。受影響的安裝必須直接盤點套件才能找出：Pillar 建議盤點 OpenCode 本身，而不是等待情報來源，而 Cloud Security Alliance 的備註則建議查詢 opencode-ai 套件的版本，因為沒有可供情報來源比對的識別碼。無法升級且使用 Windows 或 Windows Subsystem for Linux 的團隊，應從其 OpenCode 設定中移除未經審查的遠端 MCP 伺服器；opencode mcp list 會顯示有哪些伺服器存在。

對於任何維護 MCP 用戶端的人來說，Pillar 的指引比一般建議更為狹窄：將 URL 以引數向量（argument vector）的形式傳遞，絕不從遠端字串建構命令列；把 OAuth 探索綁定到使用者所設定之伺服器的來源（origin）；並將探索文件、伺服器中介資料與工具描述元視為不受信任的輸入，而非設定值。Cloud Security Alliance 的說明補充了追查用的啟發式規則——例如某個 OpenCode 程序生成 powershell.exe並搭配 -EncodedCommand，舉例來說；同時強調這些僅是供偵測工程參考的建議，並非已公布的入侵指標。

不是 Console 的入侵事件

Pillar 的披露是在 Anomaly 確認 OpenCode 的託管 Console 另一起外洩事件數天後出現，該事件可能已暴露所儲存的 API 供應商金鑰。這兩起事件並無關聯，而 Pillar 的 Eilon Cohen 在接受 Infosecurity Magazine 採訪時明確說明了差異。「這起外洩事件擊中託管金鑰代理後方的舊系統，並暴露了使用者在該處儲存的供應商金鑰，」他表示。「我們回報的漏洞則是相反方向：惡意遠端 MCP 伺服器在 OAuth 握手期間於開發者自己的機器上執行程式碼。目標和攻擊者位置都不同。」Console 外洩事件是檔案中的獨立紀錄，兩者應作為獨立條目閱讀。

在 Cohen 的框架中，將它們聯繫起來的是這兩者背後共同的問題：「你讓誰把憑證和輸入交給 AI 程式設計工具，以及那個工具會如何處理它們。」

揭露缺口是比漏洞本身存續更久的那一部分。一個被發現者評為重大、在依賴套件版本更新中被修掉，卻不存在於防禦者平常仰賴的任何自動化訊號中的漏洞，會讓直接盤點成為唯一的偵測方法——而廠商並未發布任何公告，告訴任何人要去做一次盤點。