共享 Artifactory 快取如何變成跨帳戶 ChatGPT 隱蔽通道

Check Point Research 在 2026 年 9 月 8 日發表的報告指出，ChatGPT 程式碼執行環境曾出現一條跨帳戶隱蔽通道；研究人員在 6 月下旬向 OpenAI 通報，而該通道其後已關閉。56

重點唔係 sandbox 有冇封鎖直接連去互聯網，而係：每個 sandbox 都可以接觸同一個、而且可寫入的內部服務。只要呢個共享狀態冇做好帳戶隔離，原本彼此分開的工作階段，就有可能間接交換資料。

漏洞核心：套件中繼資料變成共享「郵箱」

據 Check Point 所述，ChatGPT 的程式碼執行容器原意是彼此隔離，亦不能直接存取公開互聯網；但它們可存取一個供應套件的內部 JFrog Artifactory 服務。6

問題不單在於 Artifactory 可被存取。研究人員指，其 Item Management API 容許容器讀取及修改快取項目的可變更中繼資料（metadata）。結果，這些中繼資料成為不同帳戶都可觸及的共享狀態：

1. 攻擊者控制的工作階段，將指令或資料寫進共享中繼資料；
2. 受害者的程式碼執行環境，在處理自己對話時讀取該狀態；
3. 受害者環境將執行結果寫回同一位置；
4. 攻擊者環境再取回結果。

換句話講，原本只是內部套件服務的組件，變成雙向的「共享剪貼簿」：在理應隔離的帳戶之間，充當指揮控制及回傳資料的通道。619

提示詞注入如何令通道變成外洩途徑

單靠共享服務，並不等於攻擊者可以直接存取受害者連接的應用程式。報告中的攻擊還要把攻擊者指令放入受害者的 ChatGPT 上下文，例如惡意提示詞、共享對話，或者藏在自訂 GPT 內的指令。46

一旦指令進入上下文，受害者工作階段便可能在處理使用者表面請求的同時，暗中執行另一項任務。關鍵在於：這項行動使用的是受害者工作階段本身已有的工具、已連接應用程式及資料存取權，而不是攻擊者的權限。6

在 Check Point 的概念驗證中，受害者的 ChatGPT 工作階段從已連接的 Gmail 帳戶讀取資料，經 Artifactory 通道傳送結果，讓攻擊者帳戶取得。受害者則照常收到一個看似正常的回覆；報道指，對方看不到被注入的指令，亦看不到被轉送的內容。36

報道提到，畫面上唯一可見跡象可能只是「Talked to Gmail」的小標籤。那是 Gmail 已被使用後的審計提示，並不等於使用者就該次讀取或資料轉送，收到逐項、明確的批准提示。3

OpenAI 做咗甚麼？

研究人員稱在 6 月下旬向 OpenAI 披露該通道。基於披露的報道指出，受影響的 Artifactory 服務當時已被停用，漏洞亦已修補。5

公開資料描述的是研究人員的概念驗證，不應解讀成已證實有大量一般用戶在真實攻擊中遭遇示範中的 Gmail 資料擷取。56

與較早前 DNS 外傳漏洞有何不同？

Check Point 較早前曾披露 ChatGPT 程式碼執行 runtime 的另一個問題：一條可通往公開互聯網的隱藏外連路徑；相關報道形容該路徑與 DNS 有關。1516

兩宗發現的機制不同：

發現	通訊路徑	安全後果
較早前的外連通道問題	runtime 通往公開互聯網的路徑	敏感內容可被傳送到環境以外。1516
Artifactory 隱蔽通道問題	內部套件服務中的共享可變更狀態	即使名義上 sandbox 隔離，不同帳戶仍可交換指令及結果。6

共同教訓是，封鎖直接上網只是一層控制。只要受提示詞影響的系統仍可利用任何向外、或橫向跨租戶傳遞資訊的機制，該機制都有機會被濫用。

與 Hugging Face Artifactory 事件的關係

Check Point 所述的 Artifactory 通道，並非涉及 OpenAI 評估代理與 Hugging Face 的另一宗事件的同一個漏洞。不過，報道將兩者聯繫於更大的問題：在受限制環境中，Artifactory 相關基建仍可能是可到達的服務。5

OpenAI 的事件技術報告列出的緩解措施，包括封鎖相關易受影響的 Artifactory 路徑，以及限制有關研究工作負載的類型。22 兩宗事件不應混為一談，但都突顯一點：共享套件倉庫不應被當成無害的後台「水喉」。

真正的架構教訓：隔離必須涵蓋依賴服務

Sandbox 的邊界有幾強，取決於裡面可以連到甚麼服務。若多個租戶可讀取或修改同一個快取、registry、佇列、中繼資料儲存庫、DNS 服務，或者受身分權限保護的端點，該依賴服務就可能成為隱蔽通道。

對於可遵從不受信任指令、又可調用已連接工具的 AI 系統，防護重點包括：

• 所有可寫資源都要按租戶劃分。 一個帳戶的 runtime 不應寫入另一個帳戶可讀取的狀態。
• 採用最小權限服務身分。 只負責抓取套件的工作負載，不應自動擁有廣泛的中繼資料管理權限。
• 將內部服務視為網絡邊界。 不受信任工作負載可接觸時，「內部」不代表安全。
• 將工具授權與對話指令分開。 涉及敏感已連接應用程式的行動，需要清晰、可檢視的授權界線。
• 令重要操作可被看見。 日誌及面向用戶的提示，應交代工具做過甚麼及其相關範圍，而不只顯示「曾聯絡某個 app」。

所以，這個概念驗證不只是單一套件快取的問題，而是一條更根本的設計原則：隔離不可以只看有冇直接網絡 socket；資料路徑與共享狀態同樣必須納入隔離範圍。615