事件背景：一份設定檔，實際上也是執行入口
MCP（Model Context Protocol）把大型語言模型連接檔案系統、資料庫與外部 API 的方式標準化。它降低整合成本，卻也讓原本需要撰寫程式、審查權限的工作，被壓縮成加入一段 mcp.json 設定。引發討論的原文指出，若開發者只是複製連線設定，可能同時接受了本機程式執行、憑證暴露與第三方套件供應鏈風險。原文見：https://dev.to/echonerve/model-context-protocol-through-the-agent-stack-lens-what-broke-whats-fixed-july-28-and-what-to-1e1e
來源事實：OX Security 在 2026 年 4 月揭露多項 MCP 相關遠端程式碼執行問題。其研究顯示，若應用程式允許不受信任的使用者提交 STDIO 伺服器設定，設定中的 command 與 args 可能直接成為主機上的程序啟動參數；LiteLLM、GPT Researcher、DocsGPT 等專案分別出現具體案例。OX 將影響描述為橫跨多種官方 SDK 的系統性設計問題：https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem/
但原文有一點必須校正：CVE-2026-30623 是 OX 列給 LiteLLM 個別弱點的識別碼，不能直接說成「四套官方 MCP SDK 共同擁有同一個 CVE」。較精確的表述是：OX 認為多個產品弱點共享 STDIO 設定進入程序執行的根因，而各產品是否構成漏洞、是否需要 CVE，仍取決於攻擊者能否跨越原本的權限邊界。
爭議核心不是能不能執行，而是誰能決定執行什麼
STDIO 型 MCP 伺服器本來就是由客戶端啟動的本機子程序。MCP 專案的安全政策明確表示，客戶端執行設定中的命令、以客戶端相同權限啟動伺服器，是預期行為；本機 MCP 伺服器應被視為與自行安裝的軟體相同的信任決定：https://github.com/modelcontextprotocol/modelcontextprotocol/security
合理推論：因此，「STDIO 可以執行程式」本身不是完整的漏洞描述。真正危險的條件是：網站介面、外部套件、專案檔案或提示注入能否在使用者不知情時改寫設定；執行程序是否持有雲端金鑰、原始碼或正式資料庫憑證；以及中間有沒有允許清單、人工確認或沙箱。若設定只能由受信任管理員修改，風險近似安裝一般程式；若低權限帳號或外部內容能間接改寫它，設定功能就可能升格為遠端執行入口。
作者觀點：MCP 的真正變化，是把「整合工具」轉化為可快速分發的設定商品。商業上，這能大幅縮短導入時間；治理上，卻容易讓團隊誤把 JSON 當成靜態資料。只要其中包含套件名稱、命令、環境變數或長效權杖，它就更接近一份具執行能力的部署清單，應接受與程式碼、CI 工作流程相同的審查。
7 月 28 日更新修的是另一組問題
這件事現在值得注意，是因為 MCP 預定於 2026 年 7 月 28 日發布新版正式規格。官方公告顯示，候選版本已於 5 月 21 日鎖定，主要變更包括移除協定層工作階段、讓遠端伺服器能使用一般輪詢負載平衡，以及強化 OAuth／OpenID Connect 授權。客戶端將依 RFC 9207 驗證授權回應的 iss，降低把某個授權伺服器回應錯配到另一伺服器的 mix-up 攻擊風險：https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
這些改動有實際價值，但不能被解讀為「MCP 安全問題已修好」。新版授權規範主要處理遠端連線、權杖簽發者與部署擴充性；它不會自動替既有 STDIO 設定加上命令允許清單，也無法判斷第三方工具描述是否可信。官方公告更明言這是破壞性更新，客戶端、伺服器與 SDK 是否同步支援，會形成一段新舊版本並存期。
實際影響與容易忽略的限制
- 本機端：逐筆盤點
command、args、套件來源及環境變數；不要把 API 金鑰直接長期留在可分享的設定檔。 - 伺服器端：若產品允許使用者新增 MCP 連線，應區分 HTTP 與 STDIO，禁止低權限帳號提交任意命令，並將本機程序置於最小權限沙箱。
- 授權端：確認權杖是否專門簽發給該 MCP 伺服器，而不是把其他服務的權杖直接轉送。官方安全指南明確把 token passthrough 列為反模式：https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices
- 監控端：記錄工具名稱、呼叫者身分、權限提升與結果狀態，但應遮蔽密碼、權杖及敏感參數。
限制也不能忽略。首先，OX 公布的受影響規模屬研究機構估算，不等於每個下載或伺服器都能由外部直接利用。其次，遠端 HTTP 並不天然比 STDIO 安全：錯誤的 OAuth、過大權限、SSRF 或權杖轉送仍可能造成資料外洩。第三，官方 Registry 驗證命名空間所有權，只能提高來源可追溯性，不能替使用者保證套件程式碼、未來版本或工具行為永遠安全。
對台灣團隊的意義與後續指標
台灣企業常同時使用本機 IDE、雲端 SaaS、私有 Git、內網資料庫與多家模型服務，MCP 正好跨越這些邊界。最務實的做法不是全面停用，而是把每個 MCP 伺服器納入軟體資產清冊：指定擁有者、資料範圍、憑證保存方式、網路出口、版本鎖定與撤除程序。正式資料庫應優先使用唯讀帳號或細分工具權限，研發筆電上的個人雲端憑證也不應與未審查的本機伺服器共享同一執行環境。
7 月 28 日後可持續觀察四項指標：正式規格是否如期發布；主要 SDK 何時完整支援且預設啟用新版授權要求；客戶端是否清楚顯示協定降版與 STDIO 程序權限；以及受影響專案是否封鎖「使用者輸入直接進入命令執行」的路徑。真正成熟的訊號，不是產品頁寫著「支援 MCP」，而是團隊能回答：這個伺服器由誰發布、以誰的權限執行、能讀寫哪些資料，以及出事時能否迅速停用與追查。