MCP 漏洞恐波及 1.5 億下載
Ox Security 指出，MCP 設計缺陷可能影響 1.5 億次下載、200 多個開源專案，還有最高 20 萬個脆弱實例。
Ox Security 指出，MCP 設計缺陷可能讓攻擊者執行指令，影響 1.5 億次下載與最高 20 萬個脆弱實例。
這篇在講一個很麻煩的事。Model Context Protocol，也就是 MCP，可能有設計缺陷。它不是單一套件壞掉，而是很多 AI 工具共用的連接層出事。
Ox Security 在 2026 年 4 月 15 日公布報告。它說，這個問題可能影響 200 多個開源專案、7,000 多台公開伺服器，還有最多 20 萬個脆弱實例。講白了，這不是小洞，是一個會擴散的洞。
| 指標 | 報告數字 | 意義 |
|---|---|---|
| 開源專案 | 200+ | 影響範圍跨多個生態系 |
| 下載量 | 1.5 億 | 代表 SDK 擴散很廣 |
| 公開伺服器 | 7,000+ | 暴露在公開網路上 |
| 脆弱實例 | 最高 20 萬 | 顯示實際風險不小 |
問題到底卡在哪裡
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Ox Security 的說法很直接。問題出在 MCP 官方 SDK 處理 STDIO 型伺服器啟動的方式。簡單說，命令可能先跑了，錯誤訊息卻還沒來得及提醒你。
這種設計很討厭。因為一般開發流程會靠失敗訊號擋掉壞參數。結果現在變成，開發工具還在往前跑，惡意指令已經先執行。
報告點名 MCP 的官方 SDK，涵蓋 Python、TypeScript、Java、Rust。Ox Security 也說，這可能導致任意指令執行，後果包括 API key 外洩、內部資料庫被碰、聊天紀錄被翻。
- 執行路徑：STDIO 介面啟動本機伺服器
- 風險結果：任意指令執行
- 可能外洩：資料、API key、資料庫、聊天紀錄
- 受影響語言：Python、TypeScript、Java、Rust
為什麼這比單一漏洞更麻煩
這事麻煩的地方，不是技術花招本身。真正可怕的是，MCP 是連接 AI 模型和外部工具的通用層。它一旦出問題，很多產品會一起中招。
MCP 之所以受歡迎，是因為它讓 agent 整合變簡單。問題是，方便常常會偷走安全邊界。尤其在 AI 軟體圈，大家都在趕著上線連接器，根本沒空慢慢磨安全細節。
這裡可以直接看出供應鏈風險。不是某一家公司的 app 寫錯而已，是標準本身的預設行為，可能把錯誤放大到整個生態系。
“We are trusting these systems with increasingly sensitive data and real-world actions. If the very protocol meant to connect AI agents is this fragile and its creators will not fix it then every company and developer building on top of it needs to treat this as an immediate wake-up call,” said Kevin Curran, professor of cybersecurity at Ulster University and IEEE senior member.
Kevin Curran 這段話講得很白。當一個協定變成很多 AI 產品的共同底座，它的安全設計就不能靠運氣。
我覺得，這種問題最糟的地方是平常看不出來。等到真的被打，通常已經有很多服務在偷偷執行不該執行的東西了。
數字對比，才看得出嚴重度
如果只看「有漏洞」三個字，大家很容易滑過去。把數字攤開來看，事情就清楚多了。200 多個專案、1.5 億次下載、7,000 多台公開伺服器，這不是單點事故。
再加上最高 20 萬個脆弱實例，代表風險不是停在 GitHub README。它已經碰到真實部署環境。對開發者來說，這種規模的問題，通常不是靠一個補丁就能收尾。
Ox Security 也說，它已經做過 30 多次 responsible disclosure，還找出 10 多個高風險或重大風險 CVE。這表示它不是第一次碰這類問題，而是在看整個 AI 工具鏈的共通風險。
- Responsible disclosures：30+
- 高或重大 CVE：10+
- 受影響開源專案：200+
- 公開伺服器：7,000+
把這些數字放一起看，MCP 的問題就很像雲端早期的設定失誤。單看一台機器沒事，放大到整批部署，就會變成維運惡夢。
而且 MCP 的角色很敏感。它碰到檔案、資料庫、API，還有 agent 能做的動作。這些東西一旦被串起來，攻擊者拿到的不是一個洞，而是一條路。
開發團隊現在該做什麼
如果你的團隊有在用 MCP，先別急著相信 SDK 預設值。你要檢查每一個會啟動本機程序的地方，也要看命令字串怎麼組、怎麼轉義、怎麼記錄。
安全團隊也該盤點公開的 MCP 伺服器。哪些是直接暴露在網際網路上，哪些連到 secrets、內部資料庫、聊天紀錄，這些都要列清楚。只要 connector 能碰到敏感資料，它就該比一般 API 更嚴格。
另外，別把「官方 SDK」四個字當護身符。很多事故都是這樣來的。大家以為官方預設最安全，結果只是大家一起相信錯了。
- 先查本機程序啟動點
- 檢查命令字串與轉義處理
- 盤點公開 MCP 伺服器
- 確認是否能碰到 secrets、資料庫、聊天紀錄
對團隊來說，現在最實際的做法不是等新聞結束。是先把能跑命令的地方全掃一遍，因為這類洞通常不會自己消失。
如果你在做 AI agent，我會直接問一句：當攻擊者控制 MCP 命令字串時，什麼機制真的擋得住它？
這件事放回產業脈絡看
MCP 之所以重要，是因為它想解決一個老問題。LLM 很會講話，但它本來不會直接碰你的軟體、資料和伺服器。MCP 就是在中間補一層標準介面。
這種標準一旦普及，風險也會一起普及。以前每家公司各做各的 connector，問題分散。現在大家往同一個 protocol 靠攏，出事時就會一起抖。
這也是 AI 基礎設施最現實的一面。模型再強，最後還是要接資料、接工具、接權限。只要這一層沒設計好，後面的應用再花俏都沒用。
對台灣開發團隊來說，這種事很值得盯。很多公司正在把 LLM 接進客服、內部知識庫、工單系統，下一步就是接更多內部工具。問題不是要不要用 MCP，而是你敢不敢把它放進正式環境。
接下來該盯什麼
我會先看兩件事。第一，MCP 官方 SDK 會不會改預設行為。第二，主流框架會不會開始把命令執行改成明確 opt-in。這兩件事會直接決定風險是降下來，還是繼續被大家默默接受。
如果你現在已經在部署 MCP，別等供應商幫你想完。先把權限縮小、把公開面收起來、把能執行命令的路徑全部列出來。這種工作很無聊，但很省命。
說真的，這類問題最怕大家當成新聞看完就算。你今天不查，明天可能就是你的伺服器在幫別人跑指令。