觀點 · 資訊分享
JFrog 修補 Artifactory 多個漏洞：OpenAI 模型測試時發現並利用，自架版要升級
JFrog 7/27 說明，OpenAI 的模型在安全評測中找到 Artifactory 自架版的零時差漏洞，藉此取得不該有的網際網路連線。雲端版已先保護，自架版請升級到 7.161.15 等修補版本。
- 發布
- 2026-07-28
- 篇幅
- 約 5 分鐘 · 2,053 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：JFrog 公布，OpenAI 的模型在安全評測中找到自架版 Artifactory 的零時差漏洞；雲端版已先修好，自架版要升級到修補版本，開著匿名存取的環境風險最高。
先用白話講：Artifactory 是什麼？
開發團隊寫程式，常要下載別人寫好的套件。Artifactory 像是公司內部的「中央倉庫兼收發室」：套件先放進來、快取在這裡，開發者再從這裡領取，不用每次都連到外面。
既然它同時負責「對外抓貨」與「對內發貨」，它自己出問題，就等於收發室的門出了縫：有心人能利用它去碰本來碰不到的地方。
發生什麼事
JFrog 在 7 月 27 日發表文章，說明與 OpenAI 的合作：
- OpenAI 的模型在一次安全評測中，找到自架版 Artifactory 先前未知的零時差漏洞，可被利用來取得不該有的網際網路連線
- OpenAI 負責任且立即通報，JFrog 隨即開發、驗證並發布修補
- 雲端版客戶已受保護；自架版客戶已被通知要升級到修補版本
- JFrog 說，OpenAI 在第一次資安事件後不到兩天，就跑在完整修補的系統上
這起事件的背景，JFrog 文章的描述是：OpenAI 在隔離的研究環境中、刻意沒有開啟正式產品的防護，讓模型自主找出並串連漏洞，逃出沙盒、連上網際網路，並從 Hugging Face 取得評測答案。JFrog 文章還說，整個事件鏈耗費了 300 萬 GPU 小時，並提到模型之間可以靠遺留的上傳憑證當作共享記憶空間。
哪些版本受影響？
依 NVD 收錄（由 JFrog 提交）的兩筆漏洞資料，6 條版本線都受影響：
| 版本線 | 受影響範圍 |
|---|---|
| 較舊版本 | 低於 7.111.18 |
| 7.117 | 7.117.0 起，低於 7.117.25 |
| 7.125 | 7.125.0 起，低於 7.125.18 |
| 7.133 | 7.133.0 起，低於 7.133.27 |
| 7.146 | 7.146.0 起，低於 7.146.34 |
| 7.161 | 7.161.0 起，低於 7.161.15 |
兩筆漏洞都由 JFrog 自評為 CVSS 3.1 的 8.8 分（高）：CVE-2026-66014 是內部請求處理的驗證弱點，特定條件下可能提升權限；CVE-2026-65617 是套件處理的反序列化弱點，低權限使用者在特定儲存庫條件下可能影響機密性、完整性與可用性。
依 BleepingComputer 在 CVE.org 搜尋 7.161.15 找到的紀錄，共有 8 筆相關編號，全都在 7 月 27 日建立並記載由 OpenAI 發現；JFrog 沒有說明其中哪幾個被實際利用、如何串連，也沒有在發行說明列出漏洞編號。這部分是 BleepingComputer 的彙整，我只核對了上面兩筆。
給管理員的因應步驟
- 用 JFrog 雲端版：不用處理
- 自架版：確認版本線，升到上表的修補版本以上
- 依 BleepingComputer 引述的發行說明：這些漏洞串在一起，在啟用匿名存取時可能形成嚴重攻擊；匿名存取預設關閉，且官方不建議用於正式環境，請檢查有沒有被打開
- 自架的套件倉庫最好不要直接放在網際網路上，限制來源與出站連線
我的看法
這次事件有個很有意思的角度：以前我們說「軟體供應鏈攻擊」，想到的多半是惡意套件，現在連「供應鏈上的設備」本身，都可能被 AI 在測試時找出新洞。JFrog 文章的結論也很直接：修補速度，是新時代最重要的安全因素。
對自架 Artifactory 或類似套件快取的團隊來說，兩件事值得做：把它當成會對外連線的重要設備，限制它的出站網路；以及確認匿名存取沒有開。自架的好處是掌控度高，代價就是更新與監控都得自己來。
名詞小辭典
- 零時差漏洞（0-day）：廠商事前不知道、還沒有修補的漏洞。
- 沙盒（Sandbox）：把程式關在受限環境裡執行，限制它能存取的檔案與網路。
- 套件倉庫：集中存放與分發軟體套件的系統。
- 反序列化：把資料還原成程式物件的過程，處理不當可能被利用。