跳到主要内容

一个“只验证是否合法”的测试接口,让攻击者读走了整朵云的密钥:MLflow SSRF/DNS 重绑定 CVE-2026-64849 全复盘

Public

当一个机器学习平台的默认 Tracking Server 是以“无认证、SQLite、完全开放”的姿态跑起来时,它给攻击者留下的不只是模型管理界面,而是一条能直达云上密钥的管道。CVE-2026-64849 正是这样的一个漏洞:MLflow(Linux Foundation 旗下面向 AI 工程的开源平台,月下载量超过 3000 万)在 3.15.0 之前存在一处 SSRF 绕过,攻击者可借未认证的 webhook “测试”端点结合 HTTP 重定向与 DNS 重绑定,让服务器去访问本不该访问的地方——包括云服务商暴露 IAM 临时凭证的元数据端点。CVSS 9.3,且 CISA 在 2026 年 8 月把它加入 KEV 目录,理由是攻击者在漏洞 ID 分配后的几个小时内就开始扫描并实际掏走了云凭证。

一、根因:校验与执行之间,隔了一条“重定向”

问题出在“测试谁负责、被重定向到哪”被拆成了两段。MLflow 的 webhook 功能允许外部系统订阅实验、运行等事件的推送,其中 POST /api/2.0/mlflow/webhooks/{id}/test 是一个未认证的端点,用于触发测试投递。在 3.15.0 之前,这个端点调用 _validate_webhook_url() 去校验 URL——但它只校验了最初写在配置里的那个原始 URL,而真正发起 HTTP 请求、处理后续重定向的,是另一处 mlflow/webhooks/delivery.py。两个环节各自为战的结果,就是“校验挡得住 A,执行却跟到了 B”。

攻击者只要先提供一个看似正常的 URL 通过校验,再让这个 URL 返回一个指向内部地址的 HTTP 重定向,服务器端在投递时就会乖乖跟着重定向走。更隐蔽的是 DNS 重绑定:同一个域名在解析时刻返回合法 IP,等真正建立连接时又变成回环地址或内网 IP,从而绕过那些“按域名白名单”做的保护。于是,一个本意为“测试 webhook 通不通”的功能,变成了攻击者指挥服务器替自己做内网探测的工具。

二、实战路径:从 webhook 测试到 AWS 管理员钥匙

watchTowr 的研究展示了这条链能走多远。攻击者通过 SSRF 让 MLflow 服务器去请求 AWS 的元数据服务,拿到实例的 IAM 临时凭证——这一步在 KEV 收录后很快被真实攻击复现;随后利用拿到的身份访问云资源、内网管理后台,甚至对内部网络做端口扫描。这一切都不需要用户交互,复杂度低、攻击半径却直达“云上管理员身份”。

对于把 MLflow Tracking Server 直接暴露、用默认 SQLite 后端、开着模型注册表 webhook API 的团队来说,这台服务器原本就没什么防护;CVE-2026-64849 相当于给了任何路过的人一把能借这台服务器的身份去逛云的钥匙。CISA 依据 BOD 26-04 指示联邦机构限期修复,也从侧面印证了它的实战威胁,而不只是一份静态公告。

三、为什么与“普通 SSRF”不同

传统 SSRF 往往还要先绕过认证、或抢占某个高权限端口才能触达敏感位置。CVE-2026-64849 的特别之处在于,触发点本身“未认证”,且目标通常是云元数据服务这类“默认就帮你存着钥匙”的必经之地。对一个部署在云上的 AI 平台来说,这意味着一旦跑在能访问 IMDS 的节点(例如 EKS Fargate、EC2 开启 IMDSv1 的实例),漏洞就从“读几个内网页面”升级为“拿到整朵云的临时管理员凭证”。IMDSv1 的宽松默认,更放大了这种风险。

四、处置与缓解

  • 升级 MLflow 至 3.15.0 及以上,这是根治手段,同时确认 CVE ID 未再被后续版本回退影响;
  • 不要把 Tracking Server 无认证暴露到公网,为前端加反向代理与认证网关,默认 SQLite 后端不必接公网;
  • 收敛云元数据风险:尽可能启用 IMDSv2(要求 Token、禁 PUT 通配符),并给运行节点配置最小权限的 IAM 角色,即便拿到临时凭证也撬不动更多资源;
  • 锁死 webhook 投递:对 webhook URL 的校验从“原始 URL”扩展到“每次重定向后的目标”做跳转跟踪,必要时强制内网目标不可达;
  • 监控 SSRF 指纹:留意到元数据端点、回环地址、内网段的异常请求,作为不依赖版本号的第一道防线。

CVE-2026-64849 留下的经验并不新奇,却足够刺眼:AI 团队往往为了“赶紧把模型跑起来”而牺牲了最难补的安全基线——默认暴露、认证缺失、云凭证过宽。当一个“测试 webhook 通不通”的小功能都能变成通往元数据服务的暗道时,MLflow 这类平台真正需要的,不是更复杂的加密,而是把“禁止无认证触达、禁止跟随重定向跳内网、最小化云身份”这三件基本功写进默认配置。攻击者用几个小时的探测换走了密钥,而防御者要补齐的,恰恰是那些最朴素的默认值。

参考:watchTowr Labs 披露、CISA KEV 公告(CVE-2026-64849)、BleepingComputer 对 CISA 警告攻击者利用该漏洞窃取云凭证的报道、NVD 与 MITRE CVE 记录。

云安全SSRFAI平台CISA KEVDNS重绑定MLflowCVE-2026-64849元数据服务IMDS攻击面
0