北京
▲頭圖由AI輔助生成
智東西
編譯 陳佳
編輯 程茜
智東西4月17日消息， 4月15日以色列網絡安全公司OX Security發布研究報告，指出Anthropic主導開發和維護的模型上下文協議（MCP）存在架構級安全漏洞。該漏洞已影響超過3.2萬個代碼倉庫，超20萬臺服務器存在潛在暴露風險，攻擊者可借此直接竊取用戶數據、數據庫、API密鑰及聊天記錄。
據OX此次披露的研究報告，其研究團隊多次向Anthropic報告該漏洞并建議修復，Anthropic回應：“這屬于預期設計范疇。”
▲OX Security發布的《所有AI供應鏈之母：Anthropic在AI生態核心處的“設計性”安全失效》報告封面（圖源：OX Security）
該漏洞并非偶發的編碼失誤，而是被寫入Anthropic官方支持的全部10種編程語言SDK中，任何基于Anthropic MCP構建產品的開發者，都自動繼承了這一風險敞口。
MCP是Anthropic于2024年11月推出的開放標準協議，目的是讓大模型可以通過統一接口調用外部工具、數據庫和服務，目前已被微軟、亞馬遜、英偉達等大廠的AI產品廣泛集成。但OX指出，該協議在默認通信機制中缺乏基本的輸入校驗與執行邊界，使“工具調用”與“系統命令執行”之間沒有有效隔離。
OX Security研究團隊歷時五個月，完成逾30次負責任披露流程，共發現10余個嚴重級和高危級CVE漏洞。研究期間，該團隊直接在6家擁有真實付費用戶的企業生產平臺上執行了任意命令，并接管了200余個熱門開源項目中數以千計的公開服務器。
OX指出，只要Anthropic在MCP項目層面落地任何一項修復，例如限制STDIO（標準輸入輸出）接口僅執行預定義命令、在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支持的一種連接方式，開發者在配置文件中填寫命令后，MCP會啟動對應進程并建立通信。
此次漏洞的核心成因就是，MCP通過STDIO執行配置命令時，不校驗該命令是否用于啟動服務器，任何系統指令均被直接運行。更危險的是，即便進程啟動失敗并報錯，惡意命令往往也已在后臺完成執行。
▲Anthropic MCP進程執行邏輯的核心漏洞代碼片段（圖源：OX Security）
順著依賴鏈排查，OX最初認為漏洞來自一個流行的AI開發框架LangChain的MCP適配器模塊。據OX此次披露的研究報告，OX團隊聯系LangChain后，對方回應：這屬于預期設計范疇，開發者應自行負責輸入過濾。
深入溯源后，OX發現根本原因在于Anthropic的官方MCP實現代碼本身，即MCP項目中的進程啟動邏輯。
▲Anthropic模型MCP STDIO 接口遠程代碼執行漏洞原理示意圖（圖源：OX Security）
這不是某一處的編程失誤，而是Anthropic在所有官方支持的編程語言SDK中都采用了同樣的架構設計，涵蓋Python、TypeScript、Java、Kotlin、C#、Go、Ruby、Swift、PHP和Rust，共10種語言。任何基于Anthropic MCP官方代碼構建項目的開發者，都自動繼承了這一風險敞口。
▲漏洞存在于所有支持語言（圖源：OX Security）
OX向Anthropic報告后，得到了與LangChain一樣的答案：“這屬于預期設計范疇。”
約一周后，Anthropic在未通知OX的情況下更新了安全策略文檔，注明STDIO類型的MCP適配器應謹慎使用。OX認為，這一變動并未解決任何實質問題，只是更明確地表明Anthropic選擇將安全責任轉移給下游開發者。
▲所有依賴Anthropic MCP的框架均受影響，包含LangChain MCP適配器、FastMCP、Browser-Use等熱門開源項目（圖源：OX Security）
二、攻擊路徑多達五條，MCP集市形同虛設
漏洞的危險之處，在于攻擊者有多條路徑可以觸發它。
最直接的一條，是針對將MCP服務器配置界面暴露給用戶的平臺。以AI智能體平臺Letta AI為例，其界面只提供兩種MCP連接類型供用戶選擇，但OX通過攔截網絡請求，將傳輸類型替換為STDIO并附上惡意命令，最終成功在Letta AI的生產服務器上執行了任意命令。
▲第1類攻擊向量漏洞分類統計表（圖源：OX Security）
第二條路徑是繞過平臺自身的防護措施。Flowise已意識到STDIO風險并實施了輸入過濾，僅允許特定命令通過，并剝離特殊字符。但OX僅用一步就繞過了防護，利用Node.js包管理器npx的-c參數，將任意命令藏在一個被允許的命令之后傳入，防護形同虛設。
第三條路徑來自AI編程工具的提示詞注入（Prompt Injection）攻擊。Cursor、VS Code、Windsurf、Claude Code、Gemini-CLI等主流AI編程環境均支持MCP配置，且均可被操控，令AI智能體修改本地MCP配置文件，將惡意命令寫入其中。
▲AI驅動IDE通過提示注入篡改MCP配置實現本地代碼執行的攻擊鏈示意圖（圖源：OX Security）
第四條路徑針對未做身份驗證的公開服務。LangFlow是IBM旗下一款開源研究自動化框架，其設置界面直接暴露MCP配置入口，且完全不需要登錄。攻擊者只需先發一次網絡請求獲取會話令牌，再發一次配置請求注入惡意STDIO命令，即可在未登錄的情況下完全接管服務器。OX于2026年1月11日向LangFlow披露此問題，直至3月18日才通過GHSA報告獲得直接確認。
▲第2-4類攻擊向量漏洞分類統計表（圖源：OX Security）
其中Windsurf的問題最為嚴重，其MCP配置文件可被AI智能體直接寫入且不向用戶展示變更內容，整個攻擊鏈無需任何用戶確認，已被分配漏洞編號CVE-2026-30615。
▲主流AI助手在MCP配置文件編輯環節的安全交互與權限機制評測表（圖源：OX Security）
第五條路徑是通過MCP集市（Marketplace）直接分發惡意MCP包。OX向11個主流MCP集市提交了一個包含任意命令執行能力的概念驗證MCP，結果9個集市未加審查直接上架，僅GitHub的托管環境因有安全審核機制而無法提交。
▲第5類攻擊向量漏洞分類統計表（圖源：OX Security）
這意味著，一個惡意MCP包可以在被發現之前被數千名開發者安裝，每次安裝都等同于向攻擊者開放一次命令執行權限。
▲主流MCP市場惡意插件安全測試結果（圖源：OX Security）
三、6個生產平臺直接被打穿，20余萬臺服務器處于風險中
OX Security團隊披露的數據顯示，Anthropic官方MCP Python SDK累計下載量已超過7327萬次，FastMCP下載量逾2247萬次，LiteLLM下載量超過5725萬次；直接或間接依賴這些項目的代碼倉庫合計達32682個，供應鏈影響范圍巨大。
▲（圖源：OX Security）
通過網絡空間搜索引擎Shodan，OX發現7374臺公開可訪問的服務器存在直接漏洞，潛在暴露服務器數量超過20萬臺。
OX對多家企業級平臺開展了驗證性測試，成功在包括Letta AI、DocsGPT、OpenHands在內的6個企業平臺上執行了系統命令，證明該漏洞可對核心業務與用戶數據構成直接威脅，其中部分已完成修復。
各廠商的回應態度則各有不同。據OX此次披露的研究報告，Anthropic和LangChain均以“這屬于預期設計范疇”回應；FastMCP稱STDIO傳輸機制按MCP規范設計本就會啟動子進程；微軟（VS Code）認為其安全要求不符合漏洞標準；谷歌（Gemini-CLI）確認為已知問題，但暫無修復計劃；Cursor認為用戶需主動點擊接受才能觸發，屬于正常設計；Windsurf則始終未回應。
四、4項修復自動傳遞，無需逐一打補丁
OX在報告中指出，這一架構漏洞本可以在MCP設計階段就徹底避免，只需在協議層采用“安全默認”原則，而非將安全負擔轉嫁給每一個下游開發者。
OX提出了四項修復建議：
1、在協議層棄用允許用戶輸入直接流入Shell執行環境的模式，改為僅執行預定義服務器別名的“僅清單”（Manifest-Only）模式。
2、在SDK層實現命令白名單，默認封鎖sh、bash、powershell等高風險命令。
3、引入強制標志位，要求開發者顯式聲明是否啟用不安全的本地執行能力。
4、要求MCP集市建立安全清單標準，所有上架MCP包須申報所訪問的資源類型并綁定開發者身份驗簽。
OX強調，上述任何一項修復只要在Anthropic的MCP項目層面實施，保護就會自動傳遞到所有下游庫和項目，無需在數百個代碼倉庫中逐一打補丁。
結語：AI生態快速擴張，協議層的安全欠賬需要被正視
MCP目前已被業界視為AI智能體通信的標準，微軟、亞馬遜、英偉達等大廠均已在自家AI產品中集成MCP支持。協議的快速普及，使得任何架構層面的缺陷都具有極強的供應鏈放大效應，一個設計決策，沿著依賴鏈傳遞到每一種編程語言、每一個下游庫、每一個信任該協議的項目。
更值得關注的是，MCP當前的主要使用群體，恰恰是技術背景較弱的Vibe Coding開發者，即那些借助AI輔助代碼生成工具快速上線項目、但缺乏系統安全知識的開發者。他們信任官方SDK的安全性，卻不知道自己可能正在繼承一個已被明確記錄的攻擊面。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
