實證研究發布於 AIA: 2026年4月22日

Anthropic MCP 的 STDIO 啟動風險：當工具設定直接變成遠端程式碼執行（RCE）的攻擊入口

TechRadar 整理了 OX Security 的研究，指出 Anthropic MCP（Model Context Protocol，讓 AI 助理連接外部工具的協定）的 STDIO 啟動模式，會讓不可信的設定值直接被當成作業系統命令執行，影響面一路擴散到整個 MCP 生態（TechRadar 引述研究者說法，可能波及 20 萬個實例，以及 7,000 多台公開可存取的伺服器）。真正的防禦重點，是把本機 MCP server 的啟動當成特權程式碼執行邊界來管，而不是把它當成一般工具設定。

Remote Code ExecutionConfiguration ReviewRuntime IsolationMCP SecurityAgentic AI

8 項對應的 AIDEFEND 防禦手法

來源: 'This is not a traditional coding error': Experts flag potentially critical security issues at the heart of Anthropic's MCP, exposes 150 million downloads and thousands of servers to complete takeover

作者: Sead Fadilpašić

原文發布: 2026年4月16日

威脅分析

根本問題是架構設計，不是單一產品剛好寫壞。 OX 在 2026 年 4 月 15 日的技術說明裡指出，StdioServerParameters 會把命令和參數欄位直接帶進 subprocess 執行；只要開發者把使用者可控值傳進去，協定本身並沒有一個明確的安全關卡把它擋下來。
這種設計會沿著工具鏈往下傳。 類似的啟動模式也出現在 LangChain adapter，以及其他會替 MCP 設定做轉接，或直接把 MCP 設定暴露出來的產品。一旦底層函式庫把「設定值直接變成命令執行」視為預設做法，很多產品就會一起繼承相同的攻擊面和影響範圍。
只靠輸入過濾，防線很脆弱。 OX 拿 Flowise 做的案例很有代表性：就算先做了一層 allowlist，攻擊者還是能靠 npx -c 這種看起來合法的包裝路徑，把任意命令一起帶進去。只要底層架構仍然允許任意 subprocess 啟動，這種過濾很快就會被繞過。
攻擊路徑同時涵蓋伺服器接管，以及本機端執行環境遭到入侵。 OX 描述了已登入和未登入都可能打到正式環境伺服器的案例，也列出 Windsurf 這種情境：提示詞注入攻擊（prompt injection）先誘導系統去改 mcp.json，再加入惡意的 STDIO 項目，最後直接在使用者電腦上執行。
這已經是整個生態系的信任邊界問題。 現在真正要問的，不只是某一台 MCP server 有沒有 bug，而是任何 UI、agent、IDE、技能市集，或自動化流程，能不能把攻擊者控制的啟動參數偷偷送進會執行程式碼的 MCP client 路徑。

適用的 8 項 AIDEFEND 防禦手法

AID-H-021.001

Client-Side Configuration Enforcement

極高

MCP client 或 SDK 建立子程序（subprocess）前，應先依明確的結構定義與經簽署的端點政策，驗證每一份 MCP 啟動設定。未核准命令、透過 shell 包裝的啟動方式、可由使用者控制的參數，以及受保護 MCP 設定的變更，都要由端點防護直接擋下，避免不可信設定被轉成在本機執行的 STDIO 程式。

AID-H-025.001

Pre-Execution Static Analysis & Dangerous Construct Blocking

極高

這起事件的核心失守點，就是設定資料直接變成 subprocess 執行。把危險命令路徑、腳本包裝層、和可繞過 allowlist 的執行方式擋在前面，再加上執行前就 fail-closed 的政策檢查，能最直接地降低 MCP 設定變成任意 OS 命令執行的風險。

AID-H-018.004

Intent-Based Dynamic Capability Scoping

極高

大多數工作流程根本不需要「可以隨便啟動任意本機程序」這種權限。把每個工作階段可用的 MCP server 或啟動模板，縮到最小、而且事先核准過的集合，就能讓提示詞注入、UI 注入，或設定竄改，不會逐步變成「想跑什麼命令就跑什麼命令」的權限。

AID-H-034.001

MCP Server Deployment Profile, Transport & Exposure Baseline

高

對負責包裝或營運 MCP server 的團隊來說，這是 MCP client 強化之外的 server 端對應控制。它要求先定義部署 profile，並落實 STDIO 啟動衛生：避免透過 shell 啟動、用最小化環境執行、讓 stdout 只輸出協定內容、把 log 寫到 stderr，並在 client 能連上 server 前先通過傳輸與曝露面的基準檢查。

AID-M-009.002

Authority Envelope & Action Risk Classification

高

啟動本機 STDIO server、修改 MCP 設定、加入新的 MCP 端點或改寫命令參數，都該被歸類成高風險控制面動作，而不是一般工具設定。這項控制提供政策事實；真正的阻擋、審查或放行由 client configuration 與 pre-execution gate 執行。

AID-H-017.007

Dual-LLM Isolation Pattern

高

OX 的案例裡，有一部分就是提示詞逐步把危險的 MCP 變更帶進執行流程。把會讀不可信網頁內容、設定建議或外部文字的那個模型，和真正能提議或執行 MCP 啟動變更的高權限模型拆開，就能降低間接提示詞注入攻擊影響本機工具權限的機會。

AID-D-003.003

Agentic Tool Use & Action Policy Monitoring

中

每次 MCP STDIO 啟動都應視為一次工具動作，並記錄工具授權層的允許或拒絕結果。第一次出現的 STDIO 啟動、沒看過的命令與參數組合、MCP 設定變更、新增本機伺服器、遭封鎖的啟動，以及 npx -c 這類高風險包裝命令，都要觸發警示。這項偵測不能修正架構缺陷，但能讓團隊更快發現有人正在利用工具啟動路徑。

AID-D-004.003

Runtime Configuration & Policy Drift Detection and Monitoring

中

MCP 設定本身就是執行期控制面的一部分。偏移監控應該把實際執行中的 mcp.json、server 登錄資訊和啟動模板，跟已核准的狀態比對；一旦提示詞帶出的檔案修改或市集匯入新增了可執行路徑，就要發出警示。

身為資安防禦者，我們應該這麼做

先盤點所有能透過 STDIO 啟動 MCP server 的產品、IDE、agent 和內部服務，確認命令和參數會不會被使用者輸入、網頁內容、匯入設定檔，或技能市集內容影響。
把允許自由輸入命令的啟動方式，改成事先核准的 server 模板或 allowlist 二進位檔。若系統仍允許任意命令，就把那條路徑視為高風險程式碼執行，強制額外核准並完整記錄。
把 mcp.json 和類似的 MCP 設定檔當成受保護的控制面變更來管。只要會新增新的可執行路徑，就加上寫入保護、code review，或升級核准。
主動搜尋 npx -c、shell passthrough 旗標，或其他能把任意命令藏進 allowlist 的包裝模式，把這些繞過路徑列入審查規則。
對第一次 STDIO 啟動、異常的命令列模式、新的 MCP server 註冊，以及工作階段從讀取不可信內容一路轉向改 MCP 設定的行為，全部加上監測和警示。

1 個額外的防禦考量

本機 MCP server 的協定層安全啟動機制

除了上面對應的防禦技術，採用 MCP 的團隊還應該再往前推一層更根本的保護：讓本機 server 的啟動改成結構化、可套政策、可驗證的 manifest，而不是把自由輸入的命令字串預設當成可執行內容。

建議做法: 改用簽署過的啟動 manifest 或固定 server 模板；若真的要允許任意命令，必須額外開啟明確的危險模式旗標，並且只要流程想引入一條未事先核准的可執行路徑，就直接 fail closed。

結論

這個案例很清楚地告訴我們，agent 安全常常不是壞在模型本身，而是壞在「設定」和「執行」之間那條被低估的邊界。AIDEFEND 在 MCP client 強化、不安全程式碼執行防護、能力範圍限定，以及執行期監測上，都有很直接的對應；額外還需要補上的，是讓本機 MCP 啟動從隱含副作用變成明確、可治理的特權操作。