MCP設計缺陷波及超20萬臺服務器、3萬代碼庫，Anthropic發(fā)警示文檔草草回應

▲頭圖由AI輔助生成

智東西
編譯 陳佳
編輯 程茜

智東西4月17日消息， 4月15日以色列網絡安全公司OX Security發(fā)布研究報告，指出Anthropic主導開發(fā)和維護的模型上下文協(xié)議（MCP）存在架構級安全漏洞。該漏洞已影響超過3.2萬個代碼倉庫，超20萬臺服務器存在潛在暴露風險，攻擊者可借此直接竊取用戶數據、數據庫、API密鑰及聊天記錄。

據OX此次披露的研究報告，其研究團隊多次向Anthropic報告該漏洞并建議修復，Anthropic回應：“這屬于預期設計范疇。”

▲OX Security發(fā)布的《所有AI供應鏈之母：Anthropic在AI生態(tài)核心處的“設計性”安全失效》報告封面（圖源：OX Security）

該漏洞并非偶發(fā)的編碼失誤，而是被寫入Anthropic官方支持的全部10種編程語言SDK中，任何基于Anthropic MCP構建產品的開發(fā)者，都自動繼承了這一風險敞口。

MCP是Anthropic于2024年11月推出的開放標準協(xié)議，目的是讓大模型可以通過統(tǒng)一接口調用外部工具、數據庫和服務，目前已被微軟、亞馬遜、英偉達等大廠的AI產品廣泛集成。但OX指出，該協(xié)議在默認通信機制中缺乏基本的輸入校驗與執(zhí)行邊界，使“工具調用”與“系統(tǒng)命令執(zhí)行”之間沒有有效隔離。

OX Security研究團隊歷時五個月，完成逾30次負責任披露流程，共發(fā)現10余個嚴重級和高危級CVE漏洞。研究期間，該團隊直接在6家擁有真實付費用戶的企業(yè)生產平臺上執(zhí)行了任意命令，并接管了200余個熱門開源項目中數以千計的公開服務器。

OX指出，只要Anthropic在MCP項目層面落地任何一項修復，例如限制STDIO（標準輸入輸出）接口僅執(zhí)行預定義命令、在SDK層建立高危命令黑名單，保護就能自動傳遞至所有下游庫和項目，無需對數百個代碼倉庫逐一打補丁。

然而Anthropic至今未采取任何實質行動，僅在OX向其報告后悄然更新了一份安全策略文檔，注明STDIO適配器“應謹慎使用”。

LangChain、微軟、谷歌、Cursor、Windsurf等廠商也均以“正常設計”“不符合漏洞標準”“已知問題暫無修復計劃”等理由擱置處理。

▲OX對Anthropic MCP相關漏洞進行負責任披露的全流程時間線，覆蓋了從2025年11月至2026年4月的整個漏洞處理周期（圖源：OX Security）

一、啟動服務入口變后門，漏洞關鍵在Anthropic的官方代碼

OX的調查始于2025年11月，起點是一個名為GPT Researcher的開源項目。該項目在GitHub上擁有超過2.5萬顆星，能為大模型提供RAG（檢索增強生成）、深度調研和網頁瀏覽等能力。

OX的研究人員注意到，GPT Researcher支持用戶自定義STDIO類型的MCP服務器，用戶可以自行填寫啟動命令及參數。STDIO是MCP支持的一種連接方式，開發(fā)者在配置文件中填寫命令后，MCP會啟動對應進程并建立通信。

此次漏洞的核心成因就是，MCP通過STDIO執(zhí)行配置命令時，不校驗該命令是否用于啟動服務器，任何系統(tǒng)指令均被直接運行。更危險的是，即便進程啟動失敗并報錯，惡意命令往往也已在后臺完成執(zhí)行。

▲Anthropic MCP進程執(zhí)行邏輯的核心漏洞代碼片段（圖源：OX Security）

順著依賴鏈排查，OX最初認為漏洞來自一個流行的AI開發(fā)框架LangChain的MCP適配器模塊。據OX此次披露的研究報告，OX團隊聯系LangChain后，對方回應：這屬于預期設計范疇，開發(fā)者應自行負責輸入過濾。

深入溯源后，OX發(fā)現根本原因在于Anthropic的官方MCP實現代碼本身，即MCP項目中的進程啟動邏輯。

▲Anthropic模型MCP STDIO 接口遠程代碼執(zhí)行漏洞原理示意圖（圖源：OX Security）

這不是某一處的編程失誤，而是Anthropic在所有官方支持的編程語言SDK中都采用了同樣的架構設計，涵蓋Python、TypeScript、Java、Kotlin、C#、Go、Ruby、Swift、PHP和Rust，共10種語言。任何基于Anthropic MCP官方代碼構建項目的開發(fā)者，都自動繼承了這一風險敞口。

▲漏洞存在于所有支持語言（圖源：OX Security）

OX向Anthropic報告后，得到了與LangChain一樣的答案：“這屬于預期設計范疇。”

約一周后，Anthropic在未通知OX的情況下更新了安全策略文檔，注明STDIO類型的MCP適配器應謹慎使用。OX認為，這一變動并未解決任何實質問題，只是更明確地表明Anthropic選擇將安全責任轉移給下游開發(fā)者。

▲所有依賴Anthropic MCP的框架均受影響，包含LangChain MCP適配器、FastMCP、Browser-Use等熱門開源項目（圖源：OX Security）

二、攻擊路徑多達五條，MCP集市形同虛設

漏洞的危險之處，在于攻擊者有多條路徑可以觸發(fā)它。

最直接的一條，是針對將MCP服務器配置界面暴露給用戶的平臺。以AI智能體平臺Letta AI為例，其界面只提供兩種MCP連接類型供用戶選擇，但OX通過攔截網絡請求，將傳輸類型替換為STDIO并附上惡意命令，最終成功在Letta AI的生產服務器上執(zhí)行了任意命令。

▲第1類攻擊向量漏洞分類統(tǒng)計表（圖源：OX Security）

第二條路徑是繞過平臺自身的防護措施。Flowise已意識到STDIO風險并實施了輸入過濾，僅允許特定命令通過，并剝離特殊字符。但OX僅用一步就繞過了防護，利用Node.js包管理器npx的-c參數，將任意命令藏在一個被允許的命令之后傳入，防護形同虛設。

第三條路徑來自AI編程工具的提示詞注入（Prompt Injection）攻擊。Cursor、VS Code、Windsurf、Claude Code、Gemini-CLI等主流AI編程環(huán)境均支持MCP配置，且均可被操控，令AI智能體修改本地MCP配置文件，將惡意命令寫入其中。

▲AI驅動IDE通過提示注入篡改MCP配置實現本地代碼執(zhí)行的攻擊鏈示意圖（圖源：OX Security）

第四條路徑針對未做身份驗證的公開服務。LangFlow是IBM旗下一款開源研究自動化框架，其設置界面直接暴露MCP配置入口，且完全不需要登錄。攻擊者只需先發(fā)一次網絡請求獲取會話令牌，再發(fā)一次配置請求注入惡意STDIO命令，即可在未登錄的情況下完全接管服務器。OX于2026年1月11日向LangFlow披露此問題，直至3月18日才通過GHSA報告獲得直接確認。

▲第2-4類攻擊向量漏洞分類統(tǒng)計表（圖源：OX Security）

其中Windsurf的問題最為嚴重，其MCP配置文件可被AI智能體直接寫入且不向用戶展示變更內容，整個攻擊鏈無需任何用戶確認，已被分配漏洞編號CVE-2026-30615。
▲主流AI助手在MCP配置文件編輯環(huán)節(jié)的安全交互與權限機制評測表（圖源：OX Security）

第五條路徑是通過MCP集市（Marketplace）直接分發(fā)惡意MCP包。OX向11個主流MCP集市提交了一個包含任意命令執(zhí)行能力的概念驗證MCP，結果9個集市未加審查直接上架，僅GitHub的托管環(huán)境因有安全審核機制而無法提交。

▲第5類攻擊向量漏洞分類統(tǒng)計表（圖源：OX Security）

這意味著，一個惡意MCP包可以在被發(fā)現之前被數千名開發(fā)者安裝，每次安裝都等同于向攻擊者開放一次命令執(zhí)行權限。

▲主流MCP市場惡意插件安全測試結果（圖源：OX Security）

三、6個生產平臺直接被打穿，20余萬臺服務器處于風險中

OX Security團隊披露的數據顯示，Anthropic官方MCP Python SDK累計下載量已超過7327萬次，FastMCP下載量逾2247萬次，LiteLLM下載量超過5725萬次；直接或間接依賴這些項目的代碼倉庫合計達32682個，供應鏈影響范圍巨大。

▲（圖源：OX Security）

通過網絡空間搜索引擎Shodan，OX發(fā)現7374臺公開可訪問的服務器存在直接漏洞，潛在暴露服務器數量超過20萬臺。

OX對多家企業(yè)級平臺開展了驗證性測試，成功在包括Letta AI、DocsGPT、OpenHands在內的6個企業(yè)平臺上執(zhí)行了系統(tǒng)命令，證明該漏洞可對核心業(yè)務與用戶數據構成直接威脅，其中部分已完成修復。

各廠商的回應態(tài)度則各有不同。據OX此次披露的研究報告，Anthropic和LangChain均以“這屬于預期設計范疇”回應；FastMCP稱STDIO傳輸機制按MCP規(guī)范設計本就會啟動子進程；微軟（VS Code）認為其安全要求不符合漏洞標準；谷歌（Gemini-CLI）確認為已知問題，但暫無修復計劃；Cursor認為用戶需主動點擊接受才能觸發(fā)，屬于正常設計；Windsurf則始終未回應。

四、4項修復自動傳遞，無需逐一打補丁

OX在報告中指出，這一架構漏洞本可以在MCP設計階段就徹底避免，只需在協(xié)議層采用“安全默認”原則，而非將安全負擔轉嫁給每一個下游開發(fā)者。

OX提出了四項修復建議：

1、在協(xié)議層棄用允許用戶輸入直接流入Shell執(zhí)行環(huán)境的模式，改為僅執(zhí)行預定義服務器別名的“僅清單”（Manifest-Only）模式。

2、在SDK層實現命令白名單，默認封鎖sh、bash、powershell等高風險命令。

3、引入強制標志位，要求開發(fā)者顯式聲明是否啟用不安全的本地執(zhí)行能力。

4、要求MCP集市建立安全清單標準，所有上架MCP包須申報所訪問的資源類型并綁定開發(fā)者身份驗簽。

OX強調，上述任何一項修復只要在Anthropic的MCP項目層面實施，保護就會自動傳遞到所有下游庫和項目，無需在數百個代碼倉庫中逐一打補丁。

結語：AI生態(tài)快速擴張，協(xié)議層的安全欠賬需要被正視

MCP目前已被業(yè)界視為AI智能體通信的標準，微軟、亞馬遜、英偉達等大廠均已在自家AI產品中集成MCP支持。協(xié)議的快速普及，使得任何架構層面的缺陷都具有極強的供應鏈放大效應，一個設計決策，沿著依賴鏈傳遞到每一種編程語言、每一個下游庫、每一個信任該協(xié)議的項目。

更值得關注的是，MCP當前的主要使用群體，恰恰是技術背景較弱的Vibe Coding開發(fā)者，即那些借助AI輔助代碼生成工具快速上線項目、但缺乏系統(tǒng)安全知識的開發(fā)者。他們信任官方SDK的安全性，卻不知道自己可能正在繼承一個已被明確記錄的攻擊面。