獨(dú)立安全研究員關(guān)傲男（Aonan Guan ）聯(lián)合約翰霍普金斯大學(xué)博士生研究員劉征宇、鐘佳成，近期公開發(fā)布了一項(xiàng)跨越三家科技巨頭的AI Agent安全研究成果。
研究證實(shí)，Anthropic的Claude Code安全審查工具、Google的Gemini CLI GitHub Action，以及微軟GitHub旗下的Copilot Agent，均存在同一類被研究者命名為「評論與控制」（Comment and Control）的漏洞模式——攻擊者僅需通過Pull Request標(biāo)題、Issue評論或隱藏HTML注釋，即可劫持這些AI Agent，竊取宿主倉庫的API密鑰和訪問令牌。
這是首次有研究團(tuán)隊(duì)在跨廠商范圍內(nèi)系統(tǒng)性演示這一攻擊模式。三家公司均已確認(rèn)漏洞存在并進(jìn)行了修復(fù)，但截至發(fā)稿，均未向用戶發(fā)布正式的安全通告。
所有故事的起點(diǎn)都指向同一個結(jié)構(gòu)性缺陷：AI Agent在執(zhí)行任務(wù)時，會讀取倉庫中外部貢獻(xiàn)者提交的內(nèi)容并將其作為指令依據(jù)，但并未對這些輸入建立有效的隔離與校驗(yàn)機(jī)制。
Anthropic的Claude Code安全審查工具是最早被攻破的案例。這款運(yùn)行在GitHub Actions中的AI安全Agent，旨在自動審查Pull Request中的代碼變更，曾被Anthropic作為旗艦功能重點(diǎn)推廣。Aonan Guan在審查其源代碼時發(fā)現(xiàn)，PR標(biāo)題被直接拼接到提示詞模板中，未經(jīng)過任何過濾或轉(zhuǎn)義。與此同時，Claude CLI在調(diào)用時未啟用工具權(quán)限限制參數(shù)，子進(jìn)程完整繼承了宿主環(huán)境的所有環(huán)境變量。
攻擊效果是直接的：攻擊者只需創(chuàng)建一個PR，在標(biāo)題中嵌入精心構(gòu)造的注入文本，即可突破Claude的提示詞邊界，指示其執(zhí)行任意系統(tǒng)命令——包括讀取 ANTHROPIC_API_KEY 和 GITHUB_TOKEN 等敏感憑證。Claude會將命令執(zhí)行結(jié)果寫入 JSON 響應(yīng)，隨后自動發(fā)布為PR評論。攻擊者無需任何特殊權(quán)限，開一個PR即可完成竊取。
在驗(yàn)證了Claude Code之后，研究團(tuán)隊(duì)將目標(biāo)轉(zhuǎn)向Google的Gemini CLI GitHub Action，攻擊邏輯如出一轍。攻擊者創(chuàng)建一個帶有注入標(biāo)題的Issue，隨后在評論中逐步升級注入指令——先要求Gemini關(guān)注用戶任務(wù)，再偽造一個「可信內(nèi)容區(qū)」，聲稱當(dāng)前環(huán)境安全，允許共享 GEMINI_API_KEY 等令牌。這一策略成功覆蓋了Gemini原有的安全指令，導(dǎo)致其將完整API密鑰以Issue評論的形式公開暴露。
兩家廠商在披露過程中的處理方式存在差異。Anthropic于2025年10月收到報告后，將漏洞評級提升至CVSS 9.4（Critical級別），并將報告從公開披露轉(zhuǎn)入私有賞金計(jì)劃，最終支付100美元賞金。但Anthropic未發(fā)布CVE編號或安全通告，僅在代碼中靜默提交了修復(fù)并更新了文檔——對已固定依賴舊版本的用戶而言，他們可能至今不知自己暴露于風(fēng)險之中。Google則通過漏洞賞金計(jì)劃于2026年1月確認(rèn)了問題，發(fā)放1337美元賞金，但同樣未主動向用戶發(fā)布安全提示。
Anthropic在回應(yīng)中表示：「該工具在設(shè)計(jì)上并未針對提示詞注入進(jìn)行加固?！惯@一表態(tài)揭示了當(dāng)前AI Agent生態(tài)的深層矛盾：廠商默認(rèn)信任模型自身的安全能力，卻未在系統(tǒng)架構(gòu)層面建立縱深防御。
Google向研究者發(fā)放1337美元漏洞賞金的郵件通知
最令人警醒的案例來自GitHub自家的Copilot Agent。據(jù)GitHub于2025年7月公布的數(shù)據(jù)，該產(chǎn)品擁有超過2000萬付費(fèi)用戶，覆蓋《財富》100強(qiáng)中90%的企業(yè)。與前兩款產(chǎn)品相比，Copilot Agent在安全防護(hù)上部署了三層運(yùn)行時防御——環(huán)境變量過濾、密鑰掃描和網(wǎng)絡(luò)防火墻。這三層防線層層疊加，看似無懈可擊，卻依然被逐一擊穿。
攻擊的第一步是構(gòu)造「隱形載荷」。研究團(tuán)隊(duì)創(chuàng)建了一個GitHub Issue，正文包含一段人類可見的普通請求（如「Debug first」），同時在原始Markdown中嵌入一段HTML注釋，其中包含竊取憑證的系統(tǒng)指令。在GitHub的渲染視圖中，HTML注釋完全不可見，開發(fā)者只能看到正常內(nèi)容。然而，當(dāng)Copilot Agent被指派處理該Issue時，它解析了完整的Markdown源碼，執(zhí)行了隱藏指令。整條攻擊鏈中，人類審查者全程看到的都是正常的協(xié)作內(nèi)容。
攻擊者在Issue中嵌入隱形HTML注釋載荷（左側(cè)為渲染視圖，右側(cè)為源碼視圖）
第一道防線，環(huán)境變量過濾，最先失守。Copilot的運(yùn)行時會向子bash進(jìn)程傳遞的參數(shù)中剔除20個敏感變量，包括GITHUB_TOKEN、ANTHROPIC_API_KEY 等。然而，這一過濾僅作用于子進(jìn)程本身。父級Node.js進(jìn)程和MCP服務(wù)器進(jìn)程從未被過濾，完整持有所有敏感憑證。攻擊者只需在 bash 子進(jìn)程中執(zhí)行 ps auxeww 命令，即可讀取這些進(jìn)程的完整環(huán)境變量列表。
通過ps auxeww命令從父進(jìn)程環(huán)境中提取出明文憑證
第二道防線，密鑰掃描，同樣被繞過。Copilot在 git push 前會將提交差異發(fā)送至密鑰掃描API，按模式匹配ghs_、ghu_ 等已知令牌前綴。研究人員的應(yīng)對極為簡潔：將憑證進(jìn)行Base64編碼。編碼后的字符串不符合任何掃描規(guī)則，直接通過檢測，毫無阻礙地進(jìn)入提交隊(duì)列。
第三道防線，網(wǎng)絡(luò)防火墻，最終形同虛設(shè)。Copilot的出站連接被限制在白名單之內(nèi)。但攻擊者無需將數(shù)據(jù)發(fā)送到任何外部服務(wù)器——github.com本身就在白名單中。編碼后的憑證作為一個普通的代碼提交，經(jīng)由標(biāo)準(zhǔn)的git push流程發(fā)布到PR，攻擊者直接在GitHub上下載即可。
最終，研究團(tuán)隊(duì)從MCP服務(wù)器進(jìn)程中成功提取了 GITHUB_TOKEN、GITHUB_COPILOT_API_TOKEN、GITHUB_PERSONAL_ACCESS_TOKEN 和 COPILOT_JOB_NONCE 四項(xiàng)關(guān)鍵憑證。
研究團(tuán)隊(duì)于2026年2月向GitHub提交報告。GitHub最初以「已知問題，無法復(fù)現(xiàn)」為由關(guān)閉了報告。Aonan Guan隨后提供了逆向工程后的詳細(xì)技術(shù)證據(jù)，報告重新開啟后最終以「信息性」標(biāo)簽結(jié)案，發(fā)放500美元賞金。GitHub承認(rèn)該問題是「當(dāng)前運(yùn)行時設(shè)計(jì)的已知后果」，表示正在積極探索限制方案，但未提供具體時間表。截至本研究公開發(fā)布時，Copilot Agent仍可被此類攻擊手段利用。
Aonan Guan在研究論文中將這一攻擊模式命名為「評論與控制」（Comment and Control），名稱刻意仿照網(wǎng)絡(luò)安全領(lǐng)域經(jīng)典的「命令與控制」（Command and Control，C2）框架——在傳統(tǒng)攻擊中，C2指攻擊者與被控節(jié)點(diǎn)之間的持續(xù)通信通道；而在此處，GitHub平臺本身被異化為C2通道：PR標(biāo)題充當(dāng)指令輸入，Issue評論和Git提交充當(dāng)數(shù)據(jù)外傳路徑，攻擊者全程無需任何外部服務(wù)器，也無需在目標(biāo)環(huán)境中留下非常規(guī)痕跡。
這一攻擊模式之所以能在三款產(chǎn)品中反復(fù)奏效，根源在于AI Agent與開源協(xié)作平臺之間天然存在的信任關(guān)系。開發(fā)者賦予Agent讀寫倉庫的權(quán)限，Agent從倉庫中讀取外部貢獻(xiàn)者提交的內(nèi)容并將其作為執(zhí)行依據(jù)，而平臺本身恰恰是任何外部用戶都可以參與的空間。在這個信任鏈中，只要外部輸入未被充分隔離，攻擊就幾乎不可避免。
研究團(tuán)隊(duì)總結(jié)的三起案例共性如下表所示：
這一問題的波及范圍可能遠(yuǎn)超已披露的三款產(chǎn)品。Aonan Guan在研究中提到，同樣的模式已在開源項(xiàng)目OpenCode（GitHub上擁有約13.9萬Star）中復(fù)現(xiàn)。隨著AI編程Agent成為主流開發(fā)工作流的標(biāo)配，這一攻擊面還將持續(xù)擴(kuò)大。
值得深思的是，三家公司對此次披露的處理方式高度一致：確認(rèn)漏洞、修復(fù)代碼、支付賞金，但均未發(fā)布安全通告，也未分配CVE編號。Anthropic選擇靜默修復(fù)，Google通過賞金程序確認(rèn)后保持沉默，GitHub則將問題定性為「已知設(shè)計(jì)后果」。這背后是AI安全領(lǐng)域的結(jié)構(gòu)性困境——當(dāng)漏洞根植于模型對自然語言指令的服從性而非傳統(tǒng)代碼缺陷時，廠商往往傾向于將其視為「設(shè)計(jì)局限」而非「安全漏洞」。然而，對開發(fā)者而言，API密鑰和訪問令牌的泄露意味著攻擊者可能獲得訪問私有倉庫、云基礎(chǔ)設(shè)施乃至整個組織代碼資產(chǎn)的權(quán)限，其危害并不因定性而降低。
Aonan Guan在研究中提出了一個務(wù)實(shí)的應(yīng)對框架：將提示詞注入視為針對機(jī)器的「網(wǎng)絡(luò)釣魚」，將AI Agent視為需要遵循最小權(quán)限原則的超級員工：
「只給Agent完成其任務(wù)所需的工具和權(quán)限。即使在模型層面已部署提示詞注入防護(hù)，這些防護(hù)在當(dāng)前實(shí)踐中最終仍可被繞過。」Aonan Guan在接受The Register訪問時表示。
這一框架落實(shí)到具體操作中，核心在于兩點(diǎn)——工具授權(quán)和憑證管理。
在工具授權(quán)層面，應(yīng)采用白名單而非黑名單機(jī)制。以Anthropic的應(yīng)急修補(bǔ)為例，其選擇在 --disallowed-tools 參數(shù)中封禁ps命令，試圖阻斷攻擊者讀取進(jìn)程信息的能力。但這一黑名單思路存在先天缺陷：封禁ps后，攻擊者可通過 cat /proc/*/environ 讀取同等信息；封禁該路徑后，仍有 ls /proc/$PID/environ、env、printenv 等多種替代方式。正確的做法不是窮舉禁止哪些命令，而是明確聲明Agent只需要哪些工具——如果一個代碼審查Agent不需要執(zhí)行bash，就不應(yīng)該給它bash權(quán)限。能力邊界決定了攻擊者的操作空間。
在憑證管理層面，應(yīng)嚴(yán)格按照功能邊界控制憑證作用域。如果一個Agent的唯一職責(zé)是總結(jié)Issue，它不需要持有具備寫權(quán)限的GITHUB_TOKEN；如果它只需要讀取代碼，它不需要持有Anthropic API密鑰。憑證暴露面越小，被竊取的損失越可控。
對使用相關(guān)工具的開發(fā)者和企業(yè)，還建議采取以下措施：盡快將GitHub Actions中的AI Agent工具更新至最新版本；審查工作流中的權(quán)限配置，確保Agent僅持有完成任務(wù)所需的最小權(quán)限集；輪換此前可能暴露的API密鑰和訪問令牌；對公開倉庫啟用「要求對所有外部貢獻(xiàn)者進(jìn)行審批」選項(xiàng)，避免外部提交內(nèi)容在未經(jīng)審核的情況下直接觸發(fā)AI Agent的自動處理流程。
從2025年10月首次向Anthropic報告Claude Code漏洞，到2026年4月研究公開發(fā)布，這項(xiàng)研究歷時近六個月。在此期間，三家廠商完成了修補(bǔ)，卻無一主動告知用戶。漏洞賞金合計(jì)1937美元——其中Anthropic支付100美元，Google支付1337美元，GitHub支付500美元——而研究所涉及的產(chǎn)品正在被數(shù)千萬開發(fā)者日常使用，覆蓋了《財富》百強(qiáng)中絕大多數(shù)企業(yè)。
這組數(shù)字，或許是當(dāng)前AI安全生態(tài)最簡潔的注腳。（本文首發(fā)鈦媒體APP，作者 | 硅谷Tech_news，編輯 | 焦燕）
參考資料：
快報
根據(jù)《網(wǎng)絡(luò)安全法》實(shí)名制要求，請綁定手機(jī)號后發(fā)表評論