GitLost 漏洞：一個 GitHub Issue 就能讓 AI 代理洩露私人儲存庫

攻擊簡介

GitLost 是 GitHub 的 Agentic Workflows 功能中一個重大的間接提示注入（indirect prompt injection）漏洞，由 Noma Security 研究人員揭露。此漏洞允許未經身分驗證的攻擊者，僅需在組織的公開儲存庫中發布一個精心設計的 GitHub Issue，就能從該組織的私人儲存庫中竊取資料。 攻擊者無需任何憑證、帳號入侵或專業編碼技能——只需建立一個惡意 Issue，然後等待工作流程執行即可。

攻擊運作方式

研究人員指出，存在漏洞的 GitHub Agentic Workflow 模式具有以下特徵：

• 由 issues.assigned 事件觸發
• 讀取 Issue 的標題和內容
• 使用 add-comment 等代理工具發布評論
• 執行時具備組織內其他儲存庫（包括私人儲存庫）的讀取權限

攻擊分為四個步驟：

1. 攻擊者在使用弱點 Agentic Workflow 模式的組織所屬的公開儲存庫中，建立一個看似無害的 GitHub Issue。
2. Issue 內容中隱藏了純英文指令，指示 AI 代理從私人儲存庫中提取檔案。
3. 當 GitHub 自動化系統指派該 Issue 時，事件觸發的工作流程會讓代理去提取它有權存取的儲存庫資料，其中包括私人儲存庫。
4. 代理將提取的內容以公開評論的形式發布在該 Issue 上，導致資料可能被任何能查看該 Issue 的人取得。

底層架構弱點

此漏洞的核心缺陷在於未能嚴格區分系統層級指令與不可信賴的使用者資料之間的信任邊界，尤其是在 AI 代理的上下文視窗（context window）內。 正如 Noma 的 Sasi Levi 所言：「代理的上下文視窗就是它的攻擊面。代理讀取的任何內容——無論是 Issue、PR、評論還是檔案——如果代理將其視為指令輸入，就可能被武器化。」

基於大型語言模型（LLM）的代理在資料和指令同時出現在同一個上下文或工具輸出中時，難以區分兩者。 這不僅僅是傳統的編碼錯誤，而是代理式 AI 工作流程中的結構性風險——當工作流程未對不可信賴的內容進行隔離或限制時，此類內容就可能影響代理行為。

研究人員已將這類缺陷正式歸類為「代理式工作流程注入（Agentic Workflow Injection, AWI）」，並識別出兩種核心模式：提示轉代理（Prompt-to-Agent, P2A），即不可信賴的內容到達代理提示邊界；以及提示轉腳本（Prompt-to-Script, P2S），即攻擊者的影響透過模型產出的輸出擴散到後續腳本中。

繞過安全閘門的技巧：「Additionally」關鍵字

GitHub 設有旨在防止資料外洩的安全閘門，但 Noma 研究人員報告指出，他們能透過一種出奇簡單的技巧繞過這些防護。 只要在注入的指令中加入「Additionally」這個詞，就能讓模型重新框架其輸出，而不是拒絕執行請求，從而使資料外洩像是任務的授權延續般進行。

這種方法與更廣泛的提示注入研究結果一致，顯示特定的措辭或工具回傳的文字可能導致模型執行本不該遵循的惡意指令。 此繞過安全閘門的手法，與 Invariant Labs 先前揭露的 GitHub MCP 漏洞模式類似，當時一個惡意 Issue 也能劫持使用者的代理，從私人儲存庫中洩漏資料。

為組織建議的緩解措施

根據 GitLost 的發現與更廣泛的代理式工作流程安全指引，受影響的組織應實施以下控制措施：

• 對代理輸入採取零信任原則——絕不將使用者可控的內容視為可信賴的指令輸入，並將不可信賴的使用者資料與核心系統提示隔離。
• 套用嚴格的權限最小化原則——移除不必要的跨儲存庫存取權限，並限制代理透過公開輸出暴露資料的能力。
• 使用工具的白名單而非黑名單，並要求人工核准關卡，代理在執行發布外部可見評論或存取敏感儲存庫等敏感操作前，需經人工核准。
• 稽核 CI/CD 與儲存庫自動化工作流程中的 AI 代理整合，特別是當不可信賴的 GitHub 事件上下文被納入提示或代理輸入時。
• 在邏輯上將不可信賴的使用者輸入與系統層級指令分離，將使用者產生的文字視為不可信賴的資料，而非權威性指令。

組織也應將權限最小化原則應用於代理的機密資訊，並針對提示注入攻擊實施持續的安全監控。

GitHub 的回應狀態（截至 7 月 7 日）

根據 Dark Reading 與 Noma Security 的揭露時間表：

• Noma 已以負責任的方式向 GitHub 揭露此漏洞。
• GitHub 告知 Noma 已更新與弱點工作流程模式相關的文件，研究人員指出，當他們最後一次檢查時，該弱點配置已不再存在。
• 截至 7 月 7 日，GitHub 尚未針對 GitLost 發布正式的公開聲明或 CVE。
• 此漏洞似乎已透過移除或修訂相關文件與工作流程模板來部分解決，而非透過明確記錄的平台層級安全修復。

更大的圖景：系統性風險

GitLost 並非單一事件。它代表了一類日益常見的漏洞：當有權存取敏感資料的 AI 代理暴露於不可信賴的使用者內容時，就會發生此類問題。類似的問題已影響了 GitHub MCP 整合、Google 的 Gemini CLI 工作流程（TrustIssues 漏洞）以及 Claude Code GitHub Actions。 這些事件的共同點是，基於 LLM 的代理缺乏在相同上下文視窗中區分資料與指令的內在能力——這是一個沒有任何單一平台修補程式能完全解決的基礎架構挑戰。