CVE-2026-64849 概念验证（PoC）披露：watchTowr 监测到针对 MLflow SSRF 漏洞的攻击

sec随谈
sec随谈

sec随谈

2026年8月19日 09:36
北京

在小说阅读器读本章

去阅读

摘要

默认配置下的 MLflow 跟踪服务器（Tracking Server）可被用作访问并读取内网服务的代理。该漏洞编号为CVE-2026-64849，属于 MLflow Webhook 功能中的一个未经身份验证的全读取 SSRF（服务端请求伪造）漏洞。目前完整的技术细节和概念验证（PoC）利用代码均已公开。维护者已在MLflow 3.15.0版本中修复了此问题。

为什么这很关键

MLflow 是一个被广泛使用的开源机器学习工作流平台。其默认的跟踪服务器在运行时未开启任何身份验证。因此，任何能够访问该服务器的人，都可以利用这一未经身份验证的全读取 SSRF 漏洞。

对攻击者而言，利用该漏洞的收益极高。攻击者可操纵服务器读取云实例的元数据（例如 AWS IMDS 凭证），还能访问仅限内网调用的管理员服务并扫描私有主机。

已报告的利用活动

漏洞披露后，紧急程度进一步升级。安全公司 watchTowr 报告称，已观察到针对该 MLflow 漏洞的攻击尝试。值得注意的是，该公司指出这些探测活动发生在公共 PoC 发布之后。

目前应将其视为尝试性的利用行为，而非已确认的大规模受害。watchTowr 经常观察到攻击者首先通过扫描来寻找暴露在外且存在漏洞的服务器。尽管如此，暴露在公网上的 MLflow 实例目前正在面临主动探测。该 CVE 漏洞的 CVSS 危险等级评分高达9.3（危急）。

攻击的工作原理

MLflow 在先前的版本中曾加入过 SSRF 防护机制。该防护机制会解析 Webhook 的主机名并拦截私有 IP 地址。然而，这一修复并不完善。

漏洞触发的关键在于：负责投递请求的代码会跟随 HTTP 重定向，且从未对最初校验过的 IP 进行绑定锁定。攻击者只需搭建一个能通过初次校验的公网 HTTPS Endpoint（端点），随后让该端点返回一个指向内网地址或云元数据地址的重定向指令。

MLflow 在跟随重定向时不会重新校验新的目标地址。又因为 Webhook 的测试接口会将响应体（Response Body）回显出来，攻击者便能直接读取到内网服务的返回内容。MLflow 官方安全公告描述了这种重定向绕过方式以及另一种 DNS 重绑定（DNS-rebinding）变体。本报告已删去任何可实际运行的漏洞利用代码。

“全读取”与“盲写”变体

全读取（Full-Read）：通过 302 重定向配合接口回显的响应，攻击者可以获得完整的数据读取能力。
盲写（Blind Write）：使用保持请求方法不变的重定向（如 307 或 308），攻击者可以实现盲写。这种写入路径能够打中那些处理 POST 请求的内网端点。

在默认配置的服务器上，上述两种攻击变体均无需任何身份验证。

受影响的版本

该漏洞影响MLflow 3.15.0 之前的全线版本。漏洞利用需要依赖 Webhook 功能，而该功能需要配置 SQL 存储后端。默认配置的 MLflow 服务器使用了 SQLite，恰好满足这一条件。

研究人员已在当时最新的发布版本以及开发分支（dev branch）上确认了该问题。此漏洞与早期在浏览器端发生的“重绑定 CSRF”漏洞并非同一个问题。

补丁与修复建议

立即升级：请毫不延迟地将 MLflow 升级至 3.15.0 或更高版本。修复补丁在每次建立连接（包括每一次重定向跳转）后，都会立即对对端 IP 进行校验，从而彻底封堵了“读取”与“写入”两种攻击路径。
临时缓解措施：在完成补丁打入之前，切勿将 MLflow 服务器暴露给不可信的网络。请通过 VPC（私有云网络）、IP 白名单或身份验证代理来限制访问。
开启认证：在可能的情况下，应开启 MLflow 可选的身份验证插件。

参考链接：

https://x.com/watchtowrcyber/status/2089685887420440637

https://github.com/mlflow/mlflow/security/advisories/GHSA-7gwp-5pfp-969j