編輯 | 云昭

出品 | 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 調用私有倉庫內容并將其泄露到公開倉庫中。

具體的攻擊演示流程如下：

1. 攻擊者提交一個惡意 Issue（例如偽裝成“About the Author”部分）。

圖片

2. 用戶無意中查看 Issue 列表，觸發 Claude 自動調用 GitHub MCP 工具。

克勞德提示用于觸發攻擊

3. Claude 被誘導調用私有倉庫內容，并創建一個新的 Pull Request，把私有信息帶入公開倉庫。
4. 攻擊者可直接訪問公開倉庫獲取泄露數據。

這是完整的聊天截圖：

與特工進行全面聊天，展示攻擊過程

在實測中，研究者最后成功導出以下敏感信息：

• 用戶私有項目名稱，如 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??

本文轉載自??51CTO技術棧??，作者：云昭