觀點 · 資訊分享

MLflow 爆授權漏洞 CVE-2026-2651:開了 --serve-artifacts,別人就能覆蓋你的模型檔

NVD 在 5 月 25 日公開 MLflow 的 CVE-2026-2651:啟用 --serve-artifacts 時,分段上傳端點沒有檢查資源層級的權限,攻擊者可以覆蓋其他使用者的檔案,進而污染模型供應鏈、在模型被載入時執行任意程式碼。

發布
2026-05-25
篇幅
約 3 分鐘 · 1,334 字
結構
7 節 + 3 題常見問題
標籤
#MLflow#CVE-2026-2651#模型供應鏈#授權缺陷#MLOps
MLflow 爆授權漏洞 CVE-2026-2651:開了 --serve-artifacts,別人就能覆蓋你的模型檔

一句話看懂:MLflow 在開啟 --serve-artifacts 時,分段上傳端點缺少權限檢查,別人可以覆蓋你的檔案,連模型都可能被換成帶惡意程式的版本。

MLflow 分段上傳端點授權漏洞資訊圖卡:開了 serve-artifacts 時,別人的檔案可被覆蓋,模型可能被下毒

先用白話講:授權缺陷是什麼?

想像一間共用倉庫,每個人只能動自己的貨架。大門口有人檢查你有沒有登記,但貨架前面沒有再檢查一次:只要你進得了倉庫,就能把別人貨架上的箱子換掉。

MLflow 這次的問題類似:它的分段上傳端點有登入檢查,卻沒有確認「你有沒有權限動這份檔案」。

發生什麼事

NVD 在 2026 年 5 月 25 日公開 CVE-2026-2651。依描述:

  • 條件:MLflow 啟用 --serve-artifacts 模式
  • 問題:/mlflow-artifacts/mpu/* 這組分段上傳(multipart upload)端點的授權邏輯,沒有強制資源層級的權限檢查
  • 後果:攻擊者可以覆蓋屬於其他使用者的檔案,可能導致跨使用者寫入、模型供應鏈污染,並在被污染的模型被載入時執行任意程式碼
  • 嚴重度:huntr 與 Red Hat 都給了 CVSS 9.0(Critical)

版本資訊要小心

NVD 的描述有一處前後對不上:

描述的位置 內容
受影響版本 3.10.1.dev0(含)以下
修正版本 3.10.0
受影響資料欄位 3.10.0 之前(lessThan 3.10.0)

「3.10.1.dev0 以下」包含了 3.10.0,卻又說 3.10.0 已修正。我沒有辦法判斷哪個是正確的,所以升級時請以 MLflow 的官方 release 與修補提交為準,NVD 的參考連結列有 GitHub 修補提交、huntr 通報頁與 Red Hat 的公告。

給開發者的技術細節

  • 先確認你有沒有啟用 --serve-artifacts,沒啟用就不在這個漏洞的條件內
  • 如果有啟用,又讓多人共用同一台伺服器,建議升級,並限制誰能連到這個服務
  • 載入別人上傳的模型前,先確認來源與完整性;尤其是用 pickle 這類會執行程式碼的格式保存的模型,載入本身就有風險
  • 檢查上傳紀錄,找有沒有不明的人覆蓋過 artifacts
  • 描述裡沒有提到需要先登入還是匿名可以利用,這點我手上的資料看不出來

我的看法

這類漏洞最麻煩的是「信任」:團隊大多會直接載入同事或自動化流程產出的模型,很少有人會去驗證每個檔案的來源。一旦檔案能被別人覆蓋,攻擊就會藏在日常流程裡。

我自己用本地模型與自架服務,最常提醒自己的是:下載或載入模型,也要像裝軟體一樣謹慎,不是檔案副檔名看起來像模型就安全。如果你的團隊也在自架 MLflow,這次可以順便做一次盤點:誰能連進來、誰能上傳、模型有沒有簽名或雜湊值可以驗證。

名詞小辭典

  • MLflow:管理機器學習實驗與模型檔案的開源工具。
  • Artifacts:訓練過程產生的檔案,例如模型、圖表與資料集。
  • 分段上傳(Multipart Upload):把大檔案切成多段分別上傳,再組合起來。
  • 供應鏈攻擊:不直接攻擊目標,而是污染目標會使用的軟體或檔案。

資料來源

常見問題

MLflow 是什麼?
常見的開源機器學習實驗管理工具,用來記錄訓練過程、保存與管理模型檔案(artifacts)。
什麼叫「模型供應鏈污染」?
有人偷偷把模型檔換成帶惡意程式的版本,之後團隊其他人載入這個模型時,惡意程式就跟著執行。因為大家信任團隊裡的模型,所以不容易察覺。
我需要馬上處理嗎?
如果你的 MLflow 有啟用 --serve-artifacts 且多人共用,建議盡快確認版本並升級;如果只是自己一個人在本機用,風險相對低。要升級到哪個版本,NVD 的描述有矛盾,請看 MLflow 的官方 release 與修補提交。
LINE