文章总结： MLflowTrackingServer的CVE-2026-64849漏洞（影响3.15.0之前版本）因SSRF防护可被绕过，可能被攻击者利用读取云元数据并窃取凭据。文章强调这不仅是漏洞修复问题，更是凭据事件，需从版本升级、网络隔离、权限最小化三方面处置。平台、云安全、SOC团队应分别聚焦实例盘点、权限审计和日志排查。管理层需批准将实验服务纳入安全管控，避免‘试验区豁免’导致风险放大。 综合评分： 85 文章分类： 漏洞分析,云安全,安全运营,红队,安全建设

MLflow 已遭利用：一台实验服务为什么能带走云凭据

原创

tcode tcode

字节脉搏实验室

2026年8月21日 14:45 北京

在小说阅读器读本章

去阅读

    一台给算法团队做实验的 MLflow Tracking Server，通常不会被业务负责人视为“核心生产系统”。但如果它能访问云元数据、内部服务和长期凭据，这台看似辅助的实验服务就可能成为攻击者进入云权限面的跳板。

    CVE-2026-64849 影响 3.15.0 之前的 MLflow。公开公告显示，默认 Tracking Server 的部分 webhook 接口可能在未认证状态下被访问，原有 SSRF 防护又可被重定向或重新解析绕过，从而让服务器替攻击者访问内部地址或云元数据，并把响应内容返回。CISA 已将该漏洞列入已知被利用漏洞目录，安全研究机构也报告了针对云托管实例的利用活动。

    为什么现在值得读？因为这不是“AI 平台又有一个漏洞”的普通补丁新闻，而是一道架构题：实验工具是否暴露互联网、是否默认无认证、是否允许任意出站访问、是否继承了过大的云角色。四个条件叠在一起，一个应用漏洞就会被放大成云凭据事件。

先做一个决策：它是漏洞工单，还是凭据事件

    对平台团队来说，升级到 3.15.0 或更高版本是明确动作，但升级前要先判断实例是否可被外部访问、是否运行受影响版本、是否采用默认或弱认证、是否能够访问云元数据和内部控制面。只要这些条件中有多个成立，就不应把它只放进常规维护队列。

    判断的关键不是“MLflow 里有没有重要模型”。即使模型和实验数据价值有限，实例所处的网络与身份位置仍可能很高：它可能运行在带实例角色的虚拟机上，能访问对象存储、模型仓库、数据库、日志平台或内部 API。攻击者需要的未必是实验结果，而是服务器替他能看到什么。

    因此，漏洞工单的关闭条件是版本修复；凭据事件的关闭条件还包括异常访问是否被排除、潜在凭据是否被处理、下游资源是否完成回看。两者的工作量不同，不能用同一个“已升级”状态覆盖。

技术团队需要理解的不是 SSRF 名词，而是权限链

    SSRF 可以理解为“让服务器代替外部请求者访问它本来能访问的地址”。本次问题的危险在于，校验发生在最初地址，而后续跳转或重新解析没有受到同等约束；默认 webhook 测试接口还可能把上游响应内容返还。于是原本只有 MLflow 主机能访问的云元数据或内部服务，可能被间接读取。

    这条链路提醒团队：入站鉴权、URL 校验和出站网络控制必须同时存在。只修其中一层，剩余层仍可能把风险放大。即便应用没有直接保存云密钥，实例身份、工作负载身份或挂载的配置也可能提供临时凭据；临时并不等于无风险，只要有效期足以访问高价值资源，就需要调查。

    反过来，如果实例从未对外暴露，入口有强认证，出站无法访问云元数据或内部敏感网段，且工作负载身份权限很小，风险会明显降低。处置应基于这些条件，而不是看到“已被利用”就无差别停掉全部实验平台。

三类负责人，各自先做什么

    平台负责人先管实例。第一步盘点自建和云上 MLflow，包括临时实验环境、Notebook 附带服务、演示实例和历史项目；第二步确认版本并升级到 3.15.0 或更高受支持版本；第三步把管理和 webhook 接口放到明确的认证与网络边界后，关闭不必要的公网可达性。无法立即升级的实例应先隔离入口，并限制其出站访问内部地址和云元数据。

    云安全负责人先管权限。列出受影响实例绑定的实例角色、服务账号、工作负载身份和可读取的 Secret，按“外网暴露、受影响版本、存在异常请求、权限较高”四个条件排序。高风险实例优先撤销会话、轮换相关凭据、缩小角色权限，并检查对象存储、密钥管理、数据库和控制台的异常调用。不要只轮换一把显眼的 Access Key，而忽略临时会话与下游令牌。

    SOC 和事件响应团队先管时间线。保留升级前的访问日志、反向代理日志、云审计、网络流量和主机证据，寻找异常 webhook 请求、来自外部的集中探测、对元数据或内部服务的异常访问，以及随后出现的云 API 调用。若只看到互联网扫描而没有成功链路证据，可升级后加强监控；若出现敏感响应读取或凭据使用迹象，应按云身份事件扩大调查。

    研发或算法用户不需要自行复现漏洞。更有价值的是报告自己创建过哪些临时实例、端口是否公开、实例绑定过什么数据源，以及近期是否出现异常实验、模型注册或访问失败。平台团队据此补全资产图，往往比一次无差别全网扫描更快找到遗漏环境。

管理层该批准的不是一次临时加班

    这类事件暴露的是 AI 与数据平台的“试验区豁免”。不少企业对生产 API 有网关、鉴权和最小权限要求，却允许实验服务直接开端口、沿用默认配置，并继承开发账号的宽权限。实验速度因此变快，攻击路径也更短。

    管理层需要批准三项长期约束：任何可从互联网访问的实验服务必须进入资产清单和漏洞响应；实验工作负载默认使用最小权限、短期身份，不能继承个人管理员权限；云元数据和内部控制面访问要通过网络与身份双重限制。它们不是给算法团队增加审批，而是把“试验环境”从安全例外改成有边界的工作区。

信息边界

    公开资料确认 CVE-2026-64849 影响 3.15.0 之前版本，3.15.0 已修复；CISA 将其列入已知被利用漏洞目录，研究机构报告了利用活动。公开信息不足以证明每个公网 MLflow 实例都已泄露云凭据，也不能仅凭一次扫描请求判定入侵成功。企业应根据版本、可达性、认证、出站路径、身份权限和云审计决定事件级别。本文不提供可直接复现该漏洞的请求或利用步骤。

    一台实验服务是否关键，不由它的名字决定，而由它能代表谁、能访问哪里决定。升级 MLflow 是第一步；把公网入口、出站网络和云身份一起收紧，才是在修补真正的权限链。

来源

·MLflow / GitHub Security Advisory：GHSA-7gwp-5pfp-969j，2026-08-02 发布；GitHub Advisory Database 于 2026-08-17 收录，页面未注明时区。 https://github.com/mlflow/mlflow/security/advisories/GHSA-7gwp-5pfp-969j

·NVD：CVE-2026-64849，2026-08-17 发布；2026-08-20 更新，页面时间按 NVD 记录。 https://nvd.nist.gov/vuln/detail/CVE-2026-64849

·CISA：CVE-2026-64849 列入 Known Exploited Vulnerabilities Catalog，Date Added 2026-08-19。 https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-64849

·SecurityWeek：MLflow Vulnerability Exploited for Cloud Credential Theft，2026-08-20 08:05 ET。 https://www.securityweek.com/mlflow-vulnerability-exploited-for-cloud-credential-theft/

·BleepingComputer：CISA warns of hackers exploiting critical MLflow vulnerability，2026-08-20 07:06，页面未标注时区。https://www.bleepingcomputer.com/news/security/cisa-warns-of-hackers-exploiting-critical-mlflow-vulnerability/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：字节脉搏实验室 tcode tcode《MLflow 已遭利用：一台实验服务为什么能带走云凭据》