周一发布的一条 CVE 记录称，官方 Flair 0.15.0 和 0.15.1 的 wheel 中仍然包含 flair/models/clustering.py，其模型加载路径会返回 pickle.loads(joblib.load(...))。这与 2024 年的一条 CVE 位于同一个文件、同一个 sink —— 而那条 CVE 将 0.15.0 列为已修复版本。

“已修复”究竟意味着什么

聚类支持在 0.15.0 中被移除了——从文档化 API 中移除。但它并未从分发工件中删除。该模块仍在 wheel 中，并且可以通过直接导入 flair.models.clustering 访问。新的警示写得很明白：“早先记录中的修复版本并不适用于已发布的软件包。”

传统表述哪里出了错

这里的陷阱不在代码，而在 元数据。CVE 记录中的“在 0.15.0 中修复”被理解为代码已经离开软件包；实际上，它的意思是维护者停止支持该功能。任何软件成分分析扫描器只要读取 2024 年记录中的 fixed-version 字段，都会把 0.15.1 的安装标记为安全。但它并不安全。第二种误读则相反，会走向恐慌：评分分别为 8.4 和 7.8，均为 HIGH，但向量是本地——AV:L，且需要用户交互。受害者必须加载攻击者提供的模型文件。这是一个不受信任权重的供应链问题，而不是网络 RCE；只报 8.4 而不说明向量，会严重夸大风险。这两个分数都只是次级来源；NVD 尚未发布主 CVSS。

让情况更糟的时间线

Flair 0.15.0 于 2024 年 12 月 20 日上传至 PyPI。0.15.1 随后于 2025 年 2 月 5 日 发布，并自那以后一直是当前版本——大约 18 个月 里，该文件一直存在、该功能一直未写入文档，而生态系统中的元数据一直宣称问题已解决。如今也同样没有可用的修复版本。

为何这类问题会反复出现

“加载模型文件，让它运行其中的代码”是 Python 机器学习生态中最古老的风险之一，而 pickle 在其中很大一部分场景里仍是默认序列化方式。这个案例之所以具有启发性，在于失败发生在记录维护而非代码本身：一条两年前的警示把一个仍在运行的 sink 标记为已解决，而大多数组织依赖的自动化工具也确实相信了这一点。