文章發布於 AIA: 2026年4月22日

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

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

Agentic AIMCP SecurityRemote Code ExecutionSupply Chain

7 項對應的 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 路徑。

適用的 7 項 AIDEFEND 防禦手法

AID-H-029

MCP & Tool Client Security Hardening

極高

這是最直接的一條。真正失守的信任邊界，其實是 MCP client 或 SDK 這條本機啟動 STDIO server、保存設定、代管權限判斷的路徑。要做的不是只看 server 端，而是把本機啟動、快取狀態、descriptor 和權限判斷機制（permission mediation），都當成高風險的用戶端安全面來強化。

AID-H-026

Unsafe Code Execution Prevention

極高

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

AID-H-019.004

Intent-Based Dynamic Capability Scoping

極高

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

AID-M-009.002

Authority Envelope & Action Risk Classification

高

啟動本機 STDIO server、修改 MCP 設定、加入新的 MCP 端點、或改寫命令參數，這些都該被歸類成高風險控制面動作，不是一般工具設定。只有先把它們明確分級，後面的嚴格核准和預設縮權才有依據。

AID-H-018.007

Dual-LLM Isolation Pattern

高

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

AID-D-005.002

Security Monitoring & Alerting for AI

中

防禦方至少要看得到第一次 STDIO 啟動、異常的命令和參數組合、新增的本機 MCP server、還有像 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 啟動從隱含副作用變成明確、可治理的特權操作。