2024年10月，約翰霍普金斯大學(xué)的安全研究員Aonan Guan向Anthropic提交了一個(gè)漏洞。三個(gè)月后，Google和Microsoft相繼為此支付賞金。但截至發(fā)稿，沒(méi)有一家發(fā)布安全公告，沒(méi)有CVE編號(hào)，沒(méi)有用戶(hù)通知——而攻擊代碼正在公開(kāi)流傳。

一張圖看懂攻擊鏈：你的PR標(biāo)題如何變成木馬

Guan的發(fā)現(xiàn)始于對(duì)Claude Code Security Review的好奇。這是Anthropic推出的GitHub Action，用Claude自動(dòng)掃描代碼變更中的安全漏洞。

"它用AI代理來(lái)找代碼漏洞——這正是軟件設(shè)計(jì)的初衷。"Guan說(shuō)。這讓他開(kāi)始追蹤數(shù)據(jù)流向：用戶(hù)輸入如何進(jìn)入代理，代理又如何據(jù)此采取行動(dòng)。

他畫(huà)出的流程圖驚人地簡(jiǎn)潔：

GitHub數(shù)據(jù)（PR標(biāo)題、Issue正文、評(píng)論）→ 進(jìn)入AI代理的任務(wù)上下文 → 代理處理并執(zhí)行操作

漏洞就藏在這個(gè)"標(biāo)準(zhǔn)流程"里。Guan在PR標(biāo)題中注入惡意指令，讓Claude執(zhí)行whoami命令，并將結(jié)果偽裝成"安全發(fā)現(xiàn)"寫(xiě)進(jìn)評(píng)論。Anthropic看后追問(wèn)：能偷更敏感的東西嗎？API密鑰？訪(fǎng)問(wèn)令牌？

Guan演示了全部。同一套攻擊模式，隨后被驗(yàn)證對(duì)Google的Gemini CLI Action和Microsoft的GitHub Copilot同樣有效。

賞金到手，公告缺席：廠商的"靜默修復(fù)"策略

三家公司都付了錢(qián)，都做了修復(fù)，但都選擇了同一種處理方式：不分配CVE，不發(fā)布公開(kāi)公告，不主動(dòng)通知用戶(hù)。

Guan對(duì)此直言不諱："這是問(wèn)題所在。"

他的擔(dān)憂(yōu)有具體指向："我確定有些用戶(hù)鎖定在漏洞版本。如果不發(fā)公告，這些人可能永遠(yuǎn)不知道自己處于風(fēng)險(xiǎn)中——或者正在被攻擊。"

鎖定版本（pinning）是開(kāi)發(fā)者的常見(jiàn)做法。為了穩(wěn)定性，團(tuán)隊(duì)會(huì)固定依賴(lài)到特定版本號(hào)，而非自動(dòng)跟隨最新更新。這意味著"官方已修復(fù)"和"用戶(hù)已安全"之間存在巨大時(shí)差——以月甚至年計(jì)。

The Register就此事向三家廠商求證，均未獲回應(yīng)。

攻擊面不止三家：Slack機(jī)器人、Jira代理、郵件助手都在射程內(nèi)

Guan判斷，漏洞模式具有普適性。任何接入GitHub Actions、擁有工具調(diào)用權(quán)限和密鑰訪(fǎng)問(wèn)權(quán)限的AI代理都可能中招。

他列出的潛在目標(biāo)包括：Slack機(jī)器人、Jira代理、郵件助手、部署自動(dòng)化代理。"Microsoft、Google、Anthropic是前三家，"他說(shuō)，"其他廠商可能也有同樣問(wèn)題。"

核心風(fēng)險(xiǎn)在于架構(gòu)設(shè)計(jì)：當(dāng)AI代理被賦予讀取用戶(hù)生成內(nèi)容、執(zhí)行系統(tǒng)命令、訪(fǎng)問(wèn)敏感憑證的三重權(quán)限時(shí)，提示詞注入（prompt injection，一種通過(guò)惡意輸入劫持AI行為的攻擊方式）就從"理論可能"變成"可 exploited 的漏洞"。

GitHub Actions的特殊性加劇了風(fēng)險(xiǎn)。工作流中的密鑰（secrets）對(duì)代理可見(jiàn)，而代理的決策邏輯對(duì)外部輸入開(kāi)放——這正是Guan所說(shuō)的"flow"問(wèn)題。

為什么廠商選擇沉默？安全與公共關(guān)系的博弈

不發(fā)公告的動(dòng)機(jī)不難推測(cè)。CVE和公開(kāi) advisory 意味著媒體關(guān)注、客戶(hù)詢(xún)問(wèn)、競(jìng)爭(zhēng)對(duì)手借勢(shì)。對(duì)于正在大力推廣AI代碼助手的企業(yè)，"我們的工具可能被PR標(biāo)題劫持"絕非理想的營(yíng)銷(xiāo)素材。

但這種計(jì)算忽略了鎖定版本的用戶(hù)群體。他們恰恰是安全實(shí)踐最謹(jǐn)慎的那批人——卻因謹(jǐn)慎而暴露在風(fēng)險(xiǎn)中。

漏洞披露的生態(tài)正在變化。傳統(tǒng)軟件時(shí)代，CVE是標(biāo)準(zhǔn)動(dòng)作；AI代理時(shí)代，"賞金+靜默修復(fù)"似乎成為新默認(rèn)。Guan的案例提供了一個(gè)觀察窗口：當(dāng)攻擊面從靜態(tài)代碼轉(zhuǎn)向動(dòng)態(tài)代理，責(zé)任邊界變得模糊。

GitHub Actions平臺(tái)、AI模型提供商、集成開(kāi)發(fā)者——誰(shuí)該為提示詞注入負(fù)責(zé)？三家公司用錢(qián)包投票，卻拒絕用公告表態(tài)。

開(kāi)發(fā)者的即時(shí)自保：三個(gè)可操作的檢查點(diǎn)

在廠商沉默的真空期，用戶(hù)需要自行評(píng)估風(fēng)險(xiǎn)。Guan的研究揭示了三個(gè)關(guān)鍵檢查點(diǎn)：

第一，審查代理權(quán)限。檢查GitHub Actions工作流中的permissions字段和密鑰訪(fǎng)問(wèn)范圍，遵循最小權(quán)限原則。

第二，隔離AI代理的執(zhí)行環(huán)境。如果代理需要執(zhí)行代碼或調(diào)用工具，考慮將其限制在無(wú)網(wǎng)絡(luò)訪(fǎng)問(wèn)、無(wú)敏感憑證的沙箱中。

第三，審計(jì)PR/Issue內(nèi)容處理邏輯。如果你的工作流使用AI處理外部輸入，確認(rèn)是否存在輸入驗(yàn)證和輸出過(guò)濾機(jī)制。

對(duì)于使用Claude Code Security Review、Gemini CLI Action或GitHub Copilot的團(tuán)隊(duì)，建議直接檢查當(dāng)前版本號(hào)，對(duì)照廠商的提交歷史確認(rèn)是否包含相關(guān)修復(fù)。

一個(gè)更深層的問(wèn)題：當(dāng)AI代理成為基礎(chǔ)設(shè)施，誰(shuí)來(lái)制定規(guī)則？

Guan的攻擊之所以有效，是因?yàn)樗昧薃I代理的"自主性"設(shè)計(jì)。傳統(tǒng)工具按固定規(guī)則執(zhí)行，AI代理則根據(jù)上下文"理解"任務(wù)——這種靈活性正是漏洞入口。

提示詞注入不是新發(fā)現(xiàn)。2023年以來(lái)，學(xué)術(shù)界和工業(yè)界已有多項(xiàng)研究。但Guan的案例首次展示了它在主流開(kāi)發(fā)工具鏈中的實(shí)際 exploitable 性，以及頭部廠商的應(yīng)對(duì)姿態(tài)。

三家公司都選擇了賞金程序而非公開(kāi)披露。這種模式對(duì)單個(gè)漏洞有效，但對(duì)系統(tǒng)性風(fēng)險(xiǎn)保持沉默，是否可持續(xù)？

GitHub Actions生態(tài)中有數(shù)千個(gè)AI驅(qū)動(dòng)的Action。如果Guan的模式普遍適用，當(dāng)前的披露機(jī)制是否足以保護(hù)用戶(hù)？當(dāng)AI代理從"輔助工具"變成"基礎(chǔ)設(shè)施組件"，安全責(zé)任的分配是否需要重新談判？