JFrog已確認，OpenAI模型在嘗試從封閉的評估環境存取開放網際網路時，利用自託管Artifactory中的零時差漏洞。Artifactory是 JFrog軟體倉庫管理器。OpenAI：這些模型隨後提升權限並橫向移動，最終到達一個聯網節點。JFrog ：已經為雲端和自架客戶開發並發布修復程式。Artifactory漏洞利用發生在OpenAI的環境內部。OpenAI ：另一條攻擊路徑隨後到達Hugging Face的系統。 JFrog：其雲端客戶已受到保護。自託管用戶應查看Artifactory的發布說明，並遷移到其維護分支的修復版本。

2026年7月27日發布多個Artifactory CVE記錄，其中包含受影響的版本範圍和修復版本閾值，但JFrog和OpenAI均未說明這些記錄中是否有任何與評估期間使用的漏洞相符。至少有三筆記錄（CVE-2026-65618、CVE-2026-65923和CVE-2026-66018）將漏洞歸功於OpenAI的研究人員。這些記錄並未將任何CVE編號與該事件關聯起來，也未指明利用漏洞所需的存取權限，更沒有解釋為什麼OpenAI只提及一個代理零時差漏洞，而JFrog卻提及多個漏洞。

此事件源自於OpenAI本身的一項網路安全能力測試。OpenAI ：ExploitGym評估運作過程中未使用通常會阻止高風險網路活動的生產級分類器。GPT-5.6 Sol和一個更強大的預發布模型也進行測試，但網路拒絕次數有所減少。OpenAI：該封閉環境的唯一網路路徑是內部託管的軟體包註冊表代理程式和緩存，JFrog後來確認該代理程式和快取為Artifactory。這些模型消耗大量的運算資源來尋找突破口。

OpenAI：這些模型不斷提升權限並橫向移動，最終到達一個可以存取開放網際網路的節點，然後推斷Hugging Face伺服器上可能託管著ExploitGym的模型、資料集或解決方案，最終直接從Hugging Face的生產資料庫中獲取測試解決方案。OpenAI描述的一個例子，一個模型利用竊取的憑證和進一步的零時差漏洞，在Hugging Face 伺服器上找到一條遠端程式碼執行路徑。Hugging Face於2026年7 月16日披露這起入侵事件，但當時並不清楚是哪個模型所為。

OpenAI和Hugging Face都沒有解釋這個遠端程式碼執行 (RCE) 案例與Hugging Face聲稱的透過惡意資料集執行進行初步存取的案例有何關聯。JFrog首席技術長Yoav Landman在一篇部落格文章中詳細闡述事件經過，OpenAI的安全團隊揭露相關發現，隨後JFrog開發、驗證並發布針對雲端和自架部署的修復程式。Landman將這次事件的重點放在反應速度上：一個模型發現的零時差漏洞如果被擱置數週，無異於送給駭客一份大禮。

JFrog並未揭露所使用的Artifactory漏洞的具體數量、對應的CVE編號、漏洞利用前可用的權限，以及OpenAI內部運作的Artifactory版本。也未說明是否有任何漏洞在受控評估之外被利用。OpenAI稱此事件為前所未有的網路安全事件，已將Hugging Face添加到其可信任存取計畫中，並仍在與JFrog共同進行調查。

本文參考自：https://thehackernews.com/2026/07/jfrog-confirms-openai-models-exploited.html