Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！

51CTO技術棧

發布于 2025-5-27 12:13

瀏覽

0收藏

編輯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

MCP 雖然火，但安全問題其實一直不容忽視，就連大名鼎鼎的、與Claude 打得火熱的 Github MCP 服務器也出事了！

剛剛得到消息，昨天，一家名為Invariant 的安全的公司，突然披露了一個有關 GitHub MCP 集成（在 GitHub 上擁有 1.4 萬星標）的嚴重漏洞。

Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！-AI.x社區圖片

這個漏洞允許攻擊者通過精心構造的 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 調用私有倉庫內容并將其泄露到公開倉庫中。

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

Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！-AI.x社區

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

Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！-AI.x社區圖片

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

Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！-AI.x社區克勞德提示用于觸發攻擊

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

這是完整的聊天截圖：

Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！-AI.x社區與特工進行全面聊天，展示攻擊過程

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

用戶私有項目名稱，如 Jupiter Star；
其搬遷計劃（計劃移居南美）；
甚至包括薪資水平等個人隱私！

Github MCP被曝嚴重安全漏洞！一個惡意問題，開發者私有倉庫裸奔，Agent成內鬼！檢測方法來了！提防中招！-AI.x社區 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 中串聯多個目標，從而防止數據橫向流動。