編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
MCP 雖然火，但安全問題其實一直不容忽視，就連大名鼎鼎的、與Claude 打得火熱的 Github MCP 服務器也出事了！
剛剛得到消息， 昨天，一家名為Invariant 的安全的公司，突然披露了一個有關 GitHub MCP 集成（在 GitHub 上擁有 1.4 萬星標）的嚴重漏洞。
圖片
這個漏洞允許攻擊者通過精心構造的 GitHub Issue“劫持”開發者的智能代理（如 Claude Desktop 中的 Claude 4 Opus），并誘導它主動泄露私有倉庫的數據。
更令人警惕的是：這不是傳統意義上的工具被黑，而是一種全新的攻擊路徑——中毒代理流（Toxic Agent Flow）。攻擊者無需突破 GitHub 或 AI 模型， 現在，攻擊者只需要用戶的某個存儲庫中放置惡意問題，他們就可以輕松劫持用戶的代理并瘋狂利用它，比如誘導智能代理誤操作，就可能造成源代碼、公司機密甚至個人信息的外泄。
漏洞原理：如何一步步劫持 AI 代理？
這種攻擊方式也是Invirant的自動安全掃描器首次識別到。 Invirant在博文中介紹了漏洞的攻擊原理。
首先是該公司設定的攻擊場景。比方一位用戶正在使用像 Claude Desktop 這樣的本地 AI 編程客戶端，并已將 GitHub MCP 接入自己的賬戶。
我們假設用戶擁有以下兩個倉庫：
- username/public-repo：一個公開倉庫，任何 GitHub 用戶都可以提交 Issue。
- username/private-repo：一個私有倉庫，儲存著敏感代碼或企業數據。
攻擊者無需入侵，只需在公開倉庫中提交一個特制的 Issue —— 里面暗藏 prompt injection（提示注入）攻擊語句。接下來，只要用戶問 Claude 一個看似無害的問題，例如：
“幫我看看 public-repo 的 open issues。”
Claude 就會調用 GitHub MCP 去抓取 Issue 列表，結果就會觸發“注入攻擊”。攻擊語句會誘導 Claude 調用私有倉庫內容并將其泄露到公開倉庫中。
具體的攻擊演示流程如下：
- 攻擊者提交一個惡意 Issue（例如偽裝成“About the Author”部分）。
圖片
- 用戶無意中查看 Issue 列表，觸發 Claude 自動調用 GitHub MCP 工具。
克勞德提示用于觸發攻擊
- Claude 被誘導調用私有倉庫內容，并創建一個新的 Pull Request，把私有信息帶入公開倉庫。
- 攻擊者可直接訪問公開倉庫獲取泄露數據。
這是完整的聊天截圖：
與特工進行全面聊天，展示攻擊過程
在實測中，研究者最后成功導出以下敏感信息：
- 用戶私有項目名稱，如 Jupiter Star；
- 其搬遷計劃（計劃移居南美）；
- 甚至包括薪資水平等個人隱私！
commit where the agent leaks private data
這類攻擊完全繞過了 GitHub 的權限系統，利用的是用戶自身的 AI 助手。這正是“中毒代理流”的可怕之處。
研究人員還展示了一個“關于作者”的注入攻擊。
只需要在公共存儲庫中放置一個惡意問題，該問題包含一個有效載荷，代理程序在查詢公共存儲庫的問題列表時將立即執行該載荷。
什么是 Toxic Agent Flow？為何防不勝防？
這是 Invariant 首次自動檢測并披露此類漏洞。與傳統的“工具被篡改”不同，Toxic Agent Flow 不需要 MCP 本身被攻破。攻擊的本質是：智能代理暴露在不可信外部信息（如 GitHub Issue）環境下，被誘導執行惡意操作。
由于代理系統背后往往是強大的大模型（如 Claude 4、GPT-4、Gemini 等），它們對提示詞非常敏感。一旦 prompt injection 成功，就可能做出無法預期的動作，如跨倉庫訪問、隱私泄露、甚至代碼注入。
而且，即便模型本身對齊程度再高，面對這種“間接誘導 + 工具調用”的攻擊鏈，依然很難完全防御。很多用戶出于效率，會設置代理為“始終允許”調用工具，從而讓攻擊者有了可乘之機。
如何檢測與預防中毒代理流？
? 防御策略一：數據流權限控制
推薦使用專為代理系統設計的安全防護工具，如 Invariant Guardrails，它可以設置基于上下文的訪問控制策略。
例如，下面這段策略可有效阻止跨倉庫調用：
raise Violation("You can access only one repo per session.") if:
(call_before: ToolCall) -> (call_after: ToolCall)
call_before.function.name in (...repo 操作集)
call_after.function.name in (...repo 操作集)
call_before.arguments["repo"] != call_after.arguments["repo"] or
call_before.arguments["owner"] != call_after.arguments["owner"]這意味著：每次交互，智能代理只能訪問一個倉庫，避免在一個 session 中串聯多個目標，從而防止數據橫向流動。
? 防御策略二：持續安全監控
安全策略之外，還應部署實時監控系統，例如 Invariant 的 MCP-scan 掃描器。
它支持 Proxy 模式，只需將 MCP 流量引入代理通道，即可：
- 實時檢測 agent 的工具調用行為；
- 快速識別可疑請求；
- 自動生成日志審計記錄，供后期溯源。
這一方式無需改動現有代理系統，就能大幅提升可視性和防御力。
Invariant 的 MCP-scan 掃描器
注意：模型對齊 ≠ 安全無憂
有人可能會想：“Claude 4 不是對齊做得很好嗎？為啥還會被操控？”
答案是：模型對齊只能提供通用安全性，無法應對具體場景的上下文威脅。 一旦進入真實交互環境，信息輸入路徑復雜、工具鏈暴露多、提示語潛藏深，模型很難憑空識別惡意模式。
正因如此，系統級的安全機制（如訪問控制、流量審計）才是防護的最后一道防線。
總結：別讓 AI 成為下一個“內鬼”
今年以來，MCP 大紅大紫，全球各大巨頭都紛紛發布了自家的 MCP 服務器，但業內人士此前就多次提醒 MCP 帶來的安全問題日益嚴峻。
本次曝光的 GitHub MCP 漏洞，首次揭示了AI 工具鏈下的間接攻擊路徑；攻擊者可通過公開 Issue 向 AI 注入惡意提示，誘導其“自愿”泄露私有倉庫內容。
值得注意的是，這是一種系統性問題，無法靠模型修復，必須通過權限隔離 + 實時監控的方式預防；
類似攻擊未來可能在更多開發者平臺（如 GitLab Duo）中出現，行業亟需構建統一的“代理安全框架”。
如果各位正在構建 Agent 系統，或已經將 GitHub、MCP 等工具集成至開發流程中，務必重視這類新興風險。
參考鏈接：https://invariantlabs.ai/blog/mcp-github-vulnerability#mitigations
