GitHub AI Agent 爆 GitLost 漏洞公開 Issue 一句話就能搬空私人倉庫

編按：本文綜合整理自 Noma Security 研究報告（GitLost 原始 PoC）、The Register 與 The Hacker News 的獨立報導、Dark Reading 與 Cybersecurity News 的資安分析、GitHub 官方 Agentic Workflows 文件，以及 Hacker News 與 X（前 Twitter）上的資安社群討論，並加入 Siami 編輯部觀點與分析。

2026 年 7 月 7 日，總部位於以色列的 AI 安全公司 Noma Security 揭露一個被命名為 GitLost 的關鍵漏洞——任何未經驗證的攻擊者，只要在同一個組織的公開倉庫留下一則看起來無害的 GitHub Issue，就能讓 GitHub 新上線的 Agentic Workflows AI 代理，把私人倉庫裡的內容以公開留言的形式「自己搬出來」。

整起攻擊不需要任何程式碼、不需要 API 金鑰、不需要社交工程，只需要在公開 repo 開一個 Issue，然後等。

漏洞原理：信任邊界被 Agent 親手打破

GitHub 於 2026 年 2 月推出、目前仍在公開預覽階段的 Agentic Workflows，讓開發團隊可以用 Markdown 撰寫自動化流程，再交由 Claude 或 GitHub Copilot 為後端的 AI Agent 自動讀取 Issue、呼叫工具、發出回應。

Noma Labs 的研究團隊發現，被研究的那組工作流設定成：

當 Issue 被指派時觸發工作流
讀取 Issue 標題與內文
用 add-comment 工具發出回應
同時擁有對組織內其他倉庫（公開 + 私人）的讀取權限

這正是經典的**間接提示注入（Indirect Prompt Injection）**攻擊場景：攻擊者把惡意指令藏在 Issue 的內文裡，Agent 把它當成「系統指示」乖乖照辦。

「Agent 的 context window 就是它的攻擊面。任何 Agent 讀進來的內容——Issue、PR、留言、檔案——只要被當成指令處理，都能變成武器。」—— Noma Labs

攻擊流程：一位「副總」的一封信

Noma 研究人員實際演練的攻擊鏈，看起來像這樣：

攻擊者先在某個公開倉庫開一則 Issue，內文偽裝成「業務副總在拜訪客戶後需要技術細節」的請求，看起來完全正常。

接著 GitHub 內建的自動化把 Issue 標記為「已指派」，觸發 Agentic Workflow。Agent 依照注入的隱藏指令，從同一組織的私人倉庫 testlocal 抓取 README.md 的內容。

最後 Agent 自動把那段內容當作公開留言，貼回那則公開 Issue 的留言區。全世界任何人只要點開那則 Issue 就能讀到原本鎖在私人倉庫裡的資料。

完整 PoC 重現都攤在陽光下：

洩漏的內容包含：

sasinomalabs/poc（公開 repo）
sasinomalabs/remote-ping（公開 repo）
sasinomalabs/testlocal（私人 repo）

「Additionally」這個字繞過了 GitHub 防護

GitHub 並非毫無防備。The Register 引述 Noma Security 研究主管 Sasi Levi 的說法，平台內建了「嚴格的護欄（restrictive guardrails）」試圖擋下這類請求。

但研究員用攻擊者會用的方式反覆測試，發現只要在注入指令裡加上「Additionally」這個關鍵字，就會觸發模型的意外行為——它不再直接拒絕，而是把輸出「重新包裝」後送出來。等於用一個英文字就把整道防線繞過。

更麻煩的是，Levi 告訴 The Register：這類漏洞「無法單純靠修補程式碼完全解決」。Noma 原本提議 GitHub 至少補一份文件警告，提醒使用者不要把私人 repo 權限跟公開 repo 混用，但截至 2026 年 7 月 7 日，GitHub 連這份文件都還沒寫進去。

The Register 聯繫 GitHub 詢問意見，未獲任何回應。

為什麼這件事重要

GitLost 並不是「某家公司的工程師寫錯一段程式碼」這種一次性 bug。它是一個類別性、結構性的問題——任何把 LLM 接上「讀取外部輸入 + 跨權限範圍 + 公開輸出」三件組的系統，都會落入同一個陷阱。

這個洞之所以讓資安圈集體冒冷汗，有幾層意義：

零成本攻擊：攻擊者連 GitHub 帳號都不用有（只要能在公開 repo 開 Issue）。對企業內部團隊而言，這代表外部任何人都可能正在讀你家的私人倉庫。
守方結構性弱勢：傳統資安防線假設「信任邊界由程式碼強制執行」。但 Agentic 系統的信任邊界有一半是模型行為在守，而模型本質上就是「聽話」的——你叫它做什麼，它就做什麼。
沒有乾淨的修補路徑：Noma 自己承認這不是丟一個 patch 就能解決的事。需要的是整套工作流設計哲學的改變：最小權限、明確的輸入/指令分離、Agent 不能把使用者內容當成 system prompt。

這跟 2025 年 5 月 Invariant Labs 揭露的 GitHub MCP 漏洞、2025 年 12 月 Aikido Security 揭露的 PromptPwnd、以及更早 2025 年 5 月的 Tessl 案例都是同一條曲線上的點——把 LLM 接進 GitHub 動作鏈這件事，每一次新整合都會重新踩到同一類雷。

對企業 IT / DevOps 團隊來說，這篇文章的訊號很清楚：任何組織內部若已經啟用 Agentic Workflows，私人 repo 與公開 repo 的權限配置必須立刻盤點——不是等 GitHub 出 patch，而是自己先把攻擊面收斂。

數據解讀與質疑

幾個值得拆開來看的數字與矛盾：

「提示注入對 Agentic AI 如同 SQL Injection 對網頁」——這句話出自 Noma 自己的結論。把它當成行銷語言沒問題，但拿來當技術判斷依據就要打折。SQL Injection 至少有成熟的防禦框架（WAF、prepared statement、input validation），Agentic 提示注入目前連「該在哪一層防」都還沒有業界共識。
「不需要任何憑證」——攻擊者確實不需要自己的 token，但他必須能在「公開」repo 開 Issue。這代表任何對外開放 Issue 功能的組織都暴露在這個洞底下，而不是只有啟用 Agentic Workflows 的團隊。這影響半徑比 Noma 文章標題暗示的更大。
「GitHub 至 7 月 7 日仍未發任何文件」——這是 The Register 親自向 GitHub 求證的結果。在 Microsoft 收購 GitHub 滿 8 年、AI 又是微軟對外敘事核心的此刻，這種「不回應、不修補、不文件化」的三不態度，會被解讀為「優先趕進度，後面再補」。
HN 留言裡的質疑並非無的放矢——@pkkm 直接說這整篇像 Noma 的行銷操作，@jakewins 說這根本是研究人員自己把權限配錯才會發生。雙方都有道理：研究方揭露了一個真實可利用的攻擊面，但這攻擊面要被有效利用，前提是組織自己把 Agentic Workflow 配得很鬆。這不是「所有 GitHub 使用者都中招」，而是「不當配置的組織會被精準攻擊」。
漏洞有 CVE 編號嗎？——截至本文截稿，Noma 並未走 MITRE 的 CVE 編號申請流程，而是以自家命名「GitLost」發布，並透過「負責任揭露」管道私下告知 GitHub。這代表主流 CVE 資料庫（NVD、cve.mitre.org）目前還沒有這個洞的官方編號，安全團隊若只盯 CVE feed，會錯過這個洞。

給開發者與資安長的具體建議

Noma Labs 自己開出的處方籤，整理後如下：

永遠不要把使用者控制的內容當成 Agent 的可信指令輸入——任何來自 Issue、PR、留言、外部檔案的內容，都必須被當成「資料」，而不是「指令」。
權限範圍收斂到最小必要：擁有跨 repo 讀取權限的 Agent 是最高價值目標。把「能讀私人 repo」這件事設計成 opt-in 而非預設。
限制 Agent 對外公開發文的權限：尤其當輸出內容是從 Issue 內文「讀進來再寫出去」時，等於自動開了一條對外洩漏的管道。
在丟給模型前先做輸入清洗或隔離：把使用者輸入包在明確的「untrusted data」標記裡，讓模型知道那段不是指令。

額外補充幾條 Siami 編輯部的觀察：

重新檢視已啟用 Agentic Workflows 的 repo：若組織內已有任何 repo 同時擁有「公開 Issue」+「Agent 跨 repo 讀取權限」，立即暫停該 Agent 的公開回應功能，等 GitHub 釋出官方指引。
把「Agentic AI 漏洞」加入資安監控儀表板：傳統 SIEM 不會看到這種「合法 API 呼叫、把合法資料丟到公開位置」的事件。需要專門的 LLM 輸出審核層。
追蹤 GitHub Security Advisories：等 GitHub 正式發布 advisory 後，第一時間套用到所有 Agentic Workflow 設定檔。

延伸閱讀與外部資源

網友熱門留言 (5)

#1 Hacker News - @fwlr ▲ 89

提示注入對 AI Agent 來說，就像 SQL injection 對網頁應用程式那樣致命——是整個類別、整個系統性的漏洞問題，不是一次性的小瑕疵。

#2 Hacker News - @jakewins ▲ 67

這怎麼會是 GitHub 的漏洞？明明是研究人員自己給 Agent 開了私人倉庫權限、又允許它在公開 repo 回應提問，這當然會洩漏。這就像寫一個普通 CI job 給它 secret 然後讓它在公開 PR 上跑。

#3 Hacker News - @jofzar ▲ 54

為什麼『負責任揭露』這段完全沒寫 GitHub 何時修、是否承認或拒絕？是他們根本沒修嗎？

#4 Hacker News - @neya ▲ 41

大企業在投資人壓力下把 AI 硬塞進每個產品，就像當年 Adobe 一樣。消費者已經開始厭倦這套了。

#5 Hacker News - @pkkm ▲ 38

整篇讀起來像 Noma 的行銷操作。可愛的名字、Logo、誇張標題、面對非技術讀者的戲劇化語氣……真正的漏洞說穿了不就是『你給 LLM 私人資料又讓它跟陌生人互動，它就可能會洩漏』嗎？