編輯 | 云昭

出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）

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

剛剛得到消息， 昨天，一家名為Invariant 的安全的公司，突然披露了一個(gè)有關(guān) GitHub MCP 集成（在 GitHub 上擁有 1.4 萬(wàn)星標(biāo)）的嚴(yán)重漏洞。

圖片

這個(gè)漏洞允許攻擊者通過(guò)精心構(gòu)造的 GitHub Issue“劫持”開(kāi)發(fā)者的智能代理（如 Claude Desktop 中的 Claude 4 Opus），并誘導(dǎo)它主動(dòng)泄露私有倉(cāng)庫(kù)的數(shù)據(jù)。

更令人警惕的是：這不是傳統(tǒng)意義上的工具被黑，而是一種全新的攻擊路徑——中毒代理流（Toxic Agent Flow）。攻擊者無(wú)需突破 GitHub 或 AI 模型， 現(xiàn)在，攻擊者只需要用戶(hù)的某個(gè)存儲(chǔ)庫(kù)中放置惡意問(wèn)題，他們就可以輕松劫持用戶(hù)的代理并瘋狂利用它，比如誘導(dǎo)智能代理誤操作，就可能造成源代碼、公司機(jī)密甚至個(gè)人信息的外泄。

漏洞原理：如何一步步劫持 AI 代理？

這種攻擊方式也是Invirant的自動(dòng)安全掃描器首次識(shí)別到。 Invirant在博文中介紹了漏洞的攻擊原理。

首先是該公司設(shè)定的攻擊場(chǎng)景。比方一位用戶(hù)正在使用像 Claude Desktop 這樣的本地 AI 編程客戶(hù)端，并已將 GitHub MCP 接入自己的賬戶(hù)。

我們假設(shè)用戶(hù)擁有以下兩個(gè)倉(cāng)庫(kù)：

• username/public-repo：一個(gè)公開(kāi)倉(cāng)庫(kù)，任何 GitHub 用戶(hù)都可以提交 Issue。
• username/private-repo：一個(gè)私有倉(cāng)庫(kù)，儲(chǔ)存著敏感代碼或企業(yè)數(shù)據(jù)。

攻擊者無(wú)需入侵，只需在公開(kāi)倉(cāng)庫(kù)中提交一個(gè)特制的 Issue —— 里面暗藏 prompt injection（提示注入）攻擊語(yǔ)句。接下來(lái)，只要用戶(hù)問(wèn) Claude 一個(gè)看似無(wú)害的問(wèn)題，例如：

“幫我看看 public-repo 的 open issues。”

Claude 就會(huì)調(diào)用 GitHub MCP 去抓取 Issue 列表，結(jié)果就會(huì)觸發(fā)“注入攻擊”。攻擊語(yǔ)句會(huì)誘導(dǎo) Claude 調(diào)用私有倉(cāng)庫(kù)內(nèi)容并將其泄露到公開(kāi)倉(cāng)庫(kù)中。

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

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

圖片

2. 用戶(hù)無(wú)意中查看 Issue 列表，觸發(fā) Claude 自動(dòng)調(diào)用 GitHub MCP 工具。

克勞德提示用于觸發(fā)攻擊

3. Claude 被誘導(dǎo)調(diào)用私有倉(cāng)庫(kù)內(nèi)容，并創(chuàng)建一個(gè)新的 Pull Request，把私有信息帶入公開(kāi)倉(cāng)庫(kù)。
4. 攻擊者可直接訪(fǎng)問(wèn)公開(kāi)倉(cāng)庫(kù)獲取泄露數(shù)據(jù)。

這是完整的聊天截圖：

與特工進(jìn)行全面聊天，展示攻擊過(guò)程

在實(shí)測(cè)中，研究者最后成功導(dǎo)出以下敏感信息：

• 用戶(hù)私有項(xiàng)目名稱(chēng)，如 Jupiter Star；
• 其搬遷計(jì)劃（計(jì)劃移居南美）；
• 甚至包括薪資水平等個(gè)人隱私！

commit where the agent leaks private data

這類(lèi)攻擊完全繞過(guò)了 GitHub 的權(quán)限系統(tǒng)，利用的是用戶(hù)自身的 AI 助手。這正是“中毒代理流”的可怕之處。

研究人員還展示了一個(gè)“關(guān)于作者”的注入攻擊。

只需要在公共存儲(chǔ)庫(kù)中放置一個(gè)惡意問(wèn)題，該問(wèn)題包含一個(gè)有效載荷，代理程序在查詢(xún)公共存儲(chǔ)庫(kù)的問(wèn)題列表時(shí)將立即執(zhí)行該載荷。

什么是 Toxic Agent Flow？為何防不勝防？

這是 Invariant 首次自動(dòng)檢測(cè)并披露此類(lèi)漏洞。與傳統(tǒng)的“工具被篡改”不同，Toxic Agent Flow 不需要 MCP 本身被攻破。攻擊的本質(zhì)是：智能代理暴露在不可信外部信息（如 GitHub Issue）環(huán)境下，被誘導(dǎo)執(zhí)行惡意操作。

由于代理系統(tǒng)背后往往是強(qiáng)大的大模型（如 Claude 4、GPT-4、Gemini 等），它們對(duì)提示詞非常敏感。一旦 prompt injection 成功，就可能做出無(wú)法預(yù)期的動(dòng)作，如跨倉(cāng)庫(kù)訪(fǎng)問(wèn)、隱私泄露、甚至代碼注入。

而且，即便模型本身對(duì)齊程度再高，面對(duì)這種“間接誘導(dǎo) + 工具調(diào)用”的攻擊鏈，依然很難完全防御。很多用戶(hù)出于效率，會(huì)設(shè)置代理為“始終允許”調(diào)用工具，從而讓攻擊者有了可乘之機(jī)。

如何檢測(cè)與預(yù)防中毒代理流？

? 防御策略一：數(shù)據(jù)流權(quán)限控制

推薦使用專(zhuān)為代理系統(tǒng)設(shè)計(jì)的安全防護(hù)工具，如 Invariant Guardrails，它可以設(shè)置基于上下文的訪(fǎng)問(wèn)控制策略。

例如，下面這段策略可有效阻止跨倉(cāng)庫(kù)調(diào)用：

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"]

這意味著：每次交互，智能代理只能訪(fǎng)問(wèn)一個(gè)倉(cāng)庫(kù)，避免在一個(gè) session 中串聯(lián)多個(gè)目標(biāo)，從而防止數(shù)據(jù)橫向流動(dòng)。

? 防御策略二：持續(xù)安全監(jiān)控

安全策略之外，還應(yīng)部署實(shí)時(shí)監(jiān)控系統(tǒng)，例如 Invariant 的 MCP-scan 掃描器。

它支持 Proxy 模式，只需將 MCP 流量引入代理通道，即可：

• 實(shí)時(shí)檢測(cè) agent 的工具調(diào)用行為；
• 快速識(shí)別可疑請(qǐng)求；
• 自動(dòng)生成日志審計(jì)記錄，供后期溯源。

這一方式無(wú)需改動(dòng)現(xiàn)有代理系統(tǒng)，就能大幅提升可視性和防御力。

Invariant 的 MCP-scan 掃描器

注意：模型對(duì)齊 ≠ 安全無(wú)憂(yōu)

有人可能會(huì)想：“Claude 4 不是對(duì)齊做得很好嗎？為啥還會(huì)被操控？”

答案是：模型對(duì)齊只能提供通用安全性，無(wú)法應(yīng)對(duì)具體場(chǎng)景的上下文威脅。 一旦進(jìn)入真實(shí)交互環(huán)境，信息輸入路徑復(fù)雜、工具鏈暴露多、提示語(yǔ)潛藏深，模型很難憑空識(shí)別惡意模式。

正因如此，系統(tǒng)級(jí)的安全機(jī)制（如訪(fǎng)問(wèn)控制、流量審計(jì)）才是防護(hù)的最后一道防線(xiàn)。

總結(jié)：別讓 AI 成為下一個(gè)“內(nèi)鬼”

今年以來(lái)，MCP 大紅大紫，全球各大巨頭都紛紛發(fā)布了自家的 MCP 服務(wù)器，但業(yè)內(nèi)人士此前就多次提醒 MCP 帶來(lái)的安全問(wèn)題日益嚴(yán)峻。

本次曝光的 GitHub MCP 漏洞，首次揭示了AI 工具鏈下的間接攻擊路徑；攻擊者可通過(guò)公開(kāi) Issue 向 AI 注入惡意提示，誘導(dǎo)其“自愿”泄露私有倉(cāng)庫(kù)內(nèi)容。

值得注意的是，這是一種系統(tǒng)性問(wèn)題，無(wú)法靠模型修復(fù)，必須通過(guò)權(quán)限隔離 + 實(shí)時(shí)監(jiān)控的方式預(yù)防；

類(lèi)似攻擊未來(lái)可能在更多開(kāi)發(fā)者平臺(tái)（如 GitLab Duo）中出現(xiàn)，行業(yè)亟需構(gòu)建統(tǒng)一的“代理安全框架”。

如果各位正在構(gòu)建 Agent 系統(tǒng)，或已經(jīng)將 GitHub、MCP 等工具集成至開(kāi)發(fā)流程中，務(wù)必重視這類(lèi)新興風(fēng)險(xiǎn)。

參考鏈接：??https://invariantlabs.ai/blog/mcp-github-vulnerability#mitigations??

本文轉(zhuǎn)載自??51CTO技術(shù)棧??，作者：云昭