（MLflow、CVE-2026-64849、2026 8月）
作者：ActiveState 工程经理兼软件工程师 Pablo Bleck
MLflow 的 Webhook API 默认开放，该平台月下载量超 30 百万次，CISA 将该未授权端点列入清单后，设定了 14 天的期限。本可更早发现该问题的那些疑问，大多在代码审查（PR）中因期限压力被忽略了
TL;DR
-
美国网络安全和基础设施安全局（CISA）将CVE-2026-64849（MLflow的webhook系统中存在的无需身份验证的SSRF绕过漏洞）添加至其已知被利用漏洞目录，该漏洞因此被归入美国管理和预算办公室（BOD）26-04的联邦机构14天修复等级。
-
MLflow 默认的跟踪服务器配置默认开放 Webhook API，该平台月下载量超 30 百万次；该漏洞使攻击者可访问内部、回环及云元数据端点，窃取包括 AWS IAM 密钥在内的云凭证
-
MLflow 3.15.0 修复了该漏洞，但打补丁是简单部分；代价高昂的部分是在紧迫期限内审计并轮换暴露端点可能访问的所有凭证
-
代码审查（PR）或依赖项采用清单应询问的三个关于默认网络暴露和凭证可达性的问题，本可在该漏洞存在 CVE 编号前就发现它
-
ActiveState 在 SLSA 级别 3 的环境中从源代码构建其库的开源组件，每个组件都有签名证明和软件物料清单（SBOM），因此默认暴露相关问题会在采用时得到解答，而非在 KEV 列入清单后
CISA 设定的 14 天期限来自政策部门。该期限最终是顺利完成补丁还是在 2 点仓促应对，取决于其他环节。本案例的问题来自代码审查环节，而非董事会层面，因为这类漏洞通常最先在该环节被发现
CISA 将 CVE-2026-64849 加入其已知被利用漏洞目录，并将其置于联邦机构需遵守的绑定运营指令（BOD）26-04 规定的 14 天修复期限层级。该漏洞为未授权 SSRF 绕过：MLflow 提交时会验证 Webhook 的 URL，但不会验证重定向后的目标地址，DNS 重绑定技术可利用该同一漏洞。MLflow 是开源 AI 平台，月下载量超 30 百万次
我的团队不使用 MLflow，但很多工程团队都在使用，且这些团队大多不是受 BOD 26-04 约束的联邦机构。联邦期限未覆盖的部分是：14 天足够打补丁，但未提及团队后续排查暴露端点已窃取凭证所需的时间
该漏洞本身很直观：MLflow 默认跟踪服务器配置暴露了未授权的 Webhook API。攻击者若能访问该 API，无需任何权限即可强制请求访问内部、回环及云元数据端点，窃取包括 AWS IAM 密钥在内的云凭证，复杂度极低
MLflow 在 3.15.0 版本中修复了该漏洞，无需任何错误配置。该功能默认开放，而 30 百万月下载量的用户都将该默认设置视为他人已做的决策
在14天内
当 KEV 列入清单恰逢冲刺中期时，排查流程如下：有人打开 CISA 通知，检查受影响的开源组件是否在环境中运行，包括内部 ML 平台（有人在 8 个月前搭建且未加入资产清单），随后开始排查
若团队没有真实的开源组件运行清单（仅依赖上次审计的电子表格），仅资产清单这一步就可能耗时一整天
确认受影响实例后，打 MLflow 补丁通常是简单部分：升级到 3.15.0，运行测试套件，重新部署
补丁未覆盖的部分是轮换暴露 Webhook 可能访问的所有凭证，因为确认攻击者是否已窃取凭证比确认端点是否已关闭更难。对于接触过云元数据端点的服务，这意味着梳理 IAM 密钥、检查日志中是否存在该 CVE 出现前无人预警的重绑定模式，若适用联邦期限则需在 14 天内完成，若不适用则按内部安全审查设定的时间线完成
ActiveState 自身的合同修复服务水平协议（SLA）规定，关键漏洞需 5 个工作日，高危漏洞 10 个工作日，其他漏洞 30 个工作日， 上游社区批准修复后启动计时，而非披露时。MLflow 在 3.15.0 发布了该修复
14 天的联邦期限处于同一时间窗口内，差异在于期限到期时补丁背后的凭证轮换工作量
三个本可更早发现该问题的疑问
这些是很多依赖项审查在期限压力下会忽略的问题：
-
默认配置是否暴露面向网络的端点？该端点是有意设计的文档内容，还是默认自带的设置？
-
该端点或其所属服务可访问的内容，是否足够接近内部、回环或云元数据地址，若从服务边界外可访问则会产生影响？
-
该端点是否默认需要身份验证，还是身份验证是后续需有人手动添加的加固步骤？
扫描工具在有特征码时可发现该问题，CI 仅在有人记得为固定版本范围编写检查时可发现
两者都无法发现一个默认未授权的 Webhook，它在运行了 8 个月的服务中安静存在，直到有人测试它是否本应可访问时才会发现问题
在构建前就检查该问题
这正是我们构建的库旨在在组件上线前解决的漏洞。 ActiveState 库中的每个组件，即跨 12 语言生态系统从源代码构建的超 79 百万个开源组件，都在 SLSA 级别 3 的环境中构建，带有签名证明和完整软件物料清单
像“该组件的默认配置是否暴露任何未授权内容”这样的问题，是我们在组件到达开发者依赖文件前即可通过溯源和构建元数据检查的内容，而非在它已在 10 个不同服务中运行后从 KEV 清单中发现的问题。 受目录管控的开源组件的 CVE 数量比直接从公共注册表拉取的相同包减少约 95%， 每个 CVE 可节省 4 至 8 个开发者小时，这意味着：在 11 点、12 天的 14 天期限内，凭证轮换工作量减少，因为问题在采用时就被问到，而非在事件响应时才发现
这就是我要强调的检查项，因为我的团队就是这么做的。如果你的审查流程在合并前无法回答“这个开源组件的默认配置暴露了什么”，那应该在自己的冲刺周期内、按自己的时间线修复，而非等 KEV 清单为你设定期限后再处理
常见问题解答
什么是 CVE-2026-64849？
它是未授权 SSRF 绕过漏洞：MLflow 提交时会验证 Webhook 的 URL，但不会验证重定向后的目标地址，DNS 重绑定技术可利用该同一漏洞。MLflow 默认跟踪服务器配置暴露了未授权的 Webhook API，攻击者若能访问该 API，无需任何权限即可强制请求访问内部、回环及云元数据端点，窃取包括 AWS IAM 密钥在内的云凭证，复杂度极低。MLflow 在 3.15.0 版本中修复了该漏洞
BOD 26-04 对非联邦机构有什么意义？
BOD 26-04 按风险层级设定修复期限，最高风险 KEV 条目为 3 天，最高达 60 天。该漏洞属于 14 天层级，仅对联邦机构有约束力。对其他机构而言，这意味着该漏洞已被确认正在被利用，任何运行受影响开源组件的团队都应自行按相同时间线进行修复，即便没有法律要求
MLflow 漏洞暴露了什么？利用该漏洞需要特殊权限吗？
不需要特殊权限。Webhook API 默认未授权，该漏洞利用 DNS 重绑定绕过 SSRF 保护，否则会阻止访问内部、回环或云元数据地址。CISA 的清单描述该漏洞复杂度低，无需权限
哪个 MLflow 版本修复了 CVE-2026-64849？
MLflow 3.15.0
在引入 MLflow 这类新开源组件前，代码审查或依赖项采用清单应询问什么？
至少应询问三点：默认配置是否暴露任何面向网络的端点，该端点是否是有文档记录的有意设计；该端点或其可访问内容是否足够接近内部、回环或云元数据地址；身份验证是默认要求，还是后续需手动添加的步骤。这三个问题可在该漏洞存在 CVE 编号前就发现这类问题