實際事件 發布於 AIA: 2026年8月24日

MLflow Webhook 轉址漏洞:公開 URL 如何讓伺服器讀取內部資源

MLflow 是用來追蹤機器學習實驗與管理模型生命週期的 MLOps 平台;本案影響接收 Webhook 的 Tracking Server。公開資安漏洞編號 CVE-2026-64849 影響 MLflow 3.13.0 與更早版本。預設 Tracking Server 的 Webhook 管理與同步測試端點不會驗證呼叫者身分。攻擊者可先註冊公開 HTTPS Webhook,再讓自己的伺服器以 302 轉址到本機、私有網路或雲端執行個體中繼資料 URL,形成伺服器端請求偽造(SSRF,讓 MLflow 代替攻擊者連到外部無法直接存取的內部服務)。MLflow 只檢查原始主機名稱,既未重新檢查轉址目標,也未固定真正連線的位址,最後還會把內部服務的回應內容傳回呼叫者。CISA 在 2026 年 8 月 19 日將此 CVE 納入已知遭利用漏洞目錄(KEV),但目錄沒有揭露攻擊者、受害者或被讀取的資料。

Credential ExposureData ExfiltrationInput ValidationSystem-Level DefenseAI Infrastructure
4 項對應的 AIDEFEND 防禦手法
來源: Unauthenticated full-read SSRF in MLflow webhook delivery (GHSA-7gwp-5pfp-969j) 
作者: freeman-bb (original private report); AUTHENSOR (independent discovery)
原文發布: 2026年8月2日

威脅分析

  • 原始 URL 的檢查與真正連線彼此脫節。_validate_webhook_url() 會解析並拒絕非公開位址,卻沒有把通過檢查的 IP 固定到後續傳送;每次轉址或重新連線都可能解析到另一個位址。這也留下 DNS 重新綁定(同一網域稍後解析到受限制內部位址)的檢查時點/使用時點落差(TOCTOU)。
  • 預設部署沒有驗證呼叫者身分。開源版預設伺服器不會載入選用的驗證外掛,因此匿名呼叫者就能建立 Webhook,並呼叫 /api/2.0/mlflow/webhooks/{id}/test
  • 302 轉址讓攻擊者讀到內部服務的回應。攻擊者控制的 HTTPS 端點把 MLflow 轉向內部目標,測試 API 再把上游狀態與回應內容傳回。公告實際展示本機機密服務,也列出雲端執行個體中繼資料與內部管理服務等可能目標。
  • 公告提供的是修正程式碼,不是已發布的修補版本。PR #24258 會檢查每次連線的對端,包括轉址目標;但 GitHub 目前仍標示沒有修補版本,因此防守方不能自行推定最低安全版本。

適用的 4 項 AIDEFEND 防禦手法

AID-H-019.001
URL Normalization & Allowlist Filtering
極高
擷取器必須逐一檢查每個轉址目標,只連到剛通過檢查的公開 IP,並把允許結果綁定最終 URL 與回傳內容;只要無法確認安全就停止。這可直接阻止 302 轉址或 DNS 重新解析把請求帶到內部位址。
AID-H-004.002
Service & API Authentication
Webhook 建立與測試操作必須使用經驗證、短效的呼叫者憑證;呼叫者身分驗證應固定在伺服器端 API 路徑上,不能依賴網路可達性或預設未啟用的選用外掛。
AID-I-002.001
Internal AI Network Segmentation
對 MLflow 工作負載套用最小權限的內部網路政策,使其無法存取執行個體中繼資料、連到本機管理服務或其他無關私有服務;即使應用層 URL 檢查失效,也能限制影響。
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
將所有 3.13.0 與更早版本的 MLflow 實例持續列為受影響資產。官方尚未列出修補版本時,應使用有期限的補償控制並保持弱點未結案;只有在含 PR #24258 的供應商版本及確切成品可供驗證後,才進行部署。

身為資安防禦者,我們應該這麼做

  • 盤點 MLflow 3.13.0 與更早版本的 Tracking Server,確認哪些 Webhook API 可從不受信任的網路連入。
  • 啟用身分驗證與授權,拒絕匿名的 Webhook 建立、更新、刪除與測試請求。
  • 在修補版本可用前,能停用 Webhook 就先停用,否則將伺服器置於限制嚴格的閘道後;同時阻擋工作負載連到鏈路本地中繼資料、本機管理服務與無關私有網路。
  • 檢查 Webhook URL、轉址遙測與測試回應,找出先連攻擊者公開主機、再轉向私有或鏈路本地位址的紀錄。
  • 若無法排除內部服務或中繼資料曾被讀取,應把可能回傳的機密視為已暴露並輪替;但不能只因產品曾暴露就斷言憑證已遭竊。

結論

這起事件的核心,是 MLflow 只檢查最初的 URL,真正連線與跟隨轉址時卻沒有再次確認目標;不驗證呼叫者身分、又會回傳內部回應內容的測試 API,進一步把問題放大。AIDEFEND  對應的安全 URL 擷取、API 身分驗證與內部網路分段,會分別阻止伺服器連到受限制位址、拒絕匿名操作,並讓 MLflow 工作負載碰不到雲端中繼資料與無關內部服務。在官方修補版本可驗證前,這些補償控制都不能撤除。CISA KEV 代表處置優先度提高,但不能據此推定受害者、惡意程式或失竊憑證。