MLflow 被披露 CVE-2026-116692，CVSS 9.8，第三方 scorer 反序列化导致未授权远程代码执行。影响 3.12.0rc0 到 3.17.0 之前的版本。
漏洞怎么发生
MLflow server 在第三方 scorer 反序列化时，会导入攻击者放置的 artifact 模块。攻击者只要能把一个构造好的 artifact 放进服务可访问的位置，就能让服务端 import 它，从而执行任意代码。整个过程不需要认证。
为什么 MLflow 是高价值目标
因为它是模型仓库。上面通常存着：模型权重、训练数据引用、实验元数据、以及最关键的云凭证（访问对象存储的 key、拉取数据集的 token）。攻击者拿下 MLflow 往往不是为了模型本身，是为了跳板进整个云环境。
三个处置动作
第一，升级到 3.17.0。这是最直接的。
第二，开启认证。MLflow 的历史设计假设你在可信内网里用，所以默认没有认证。用 basic auth 或者前置一层反向代理做身份校验都行，关键是不要让任何匿名请求能到达 tracking server。
第三，从公网摘掉。搜索一下就能发现大量暴露在互联网上的 MLflow 实例，这是长期存在的问题。tracking server 没有任何理由对公网开放。
额外的一件事
清理已上传的 artifact。如果服务曾经对不可信来源开放，需要假设可能已经有恶意 artifact 落在仓库里。遍历 artifact 目录，检查有没有不该存在的 Python 文件或者压缩包。
长期判断
ML 工具链的安全水位普遍低于同等级的业务系统，原因是它们大多起源于研究脚本，设计时考虑的是「让实验跑起来」而不是「抵抗攻击者」。现在这些工具承载的是企业的核心数据资产，这个错配必须补上。选型时把「有没有认证、有没有权限模型、有没有审计日志」当硬指标，比看功能列表重要。
一个具体的检查命令思路
列出所有 artifact 存储路径下的 .py 文件，人工过一遍。正常的 MLflow artifact 里不该有可执行脚本，除非你的流水线确实需要，那是另一套信任边界。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。
