CVE-2026-115905 是一个典型的解析器差分漏洞：Rust 生态的 zip 库在 9.0.4 及更早版本中，对同一个压缩包内的两份文件名元数据给出了两种解释，导致检查组件看到的是无害路径，而流式解压器写下去的却是攻击者指定的另一个路径。CVSS 4.0 评分 10.0，修复版本为 9.0.5，公告于 10 月 26 日公开。
问题出在 ZIP 格式自带的两份文件名
ZIP 文件里文件名的存放位置有两处：本地文件头（Local File Header，紧挨着每个条目的数据）和中央目录文件头（Central Directory File Header，集中在压缩包尾部）。规范要求两者一致，但格式本身并不强制任何读取方去校验这件事。
zip 库的两条读取路径各自信了一份：ZipArchive 以中央目录为准，这是做随机访问和列举条目的常规做法；ZipStreamReader 在流式解压时以本地文件头为准，问题在于 src/read/stream.rs 里没有把两份元数据做对账。
于是攻击者可以构造一个包：中央目录写 readme.txt，本地文件头写 ../../config/settings.json 或某个绝对路径。任何先做”安全扫描”再交给流式解压的流程，都会在这种包上失效——扫描器是清白的，因为规则本身没被绕过，是它看的那份数据跟落盘用的那份不是同一份。
为什么评分是 10.0
按 CVE 记录的 CVSS 4.0 向量，攻击向量网络、复杂度低、无攻击前提、无需权限、无需交互，机密性、完整性、可用性三项对受害系统均为高，对下游系统机密性与完整性为高。这套组合在 4.0 体系里就是天花板。
但分数不等于现实危害，几个量化指标需要分开看：EPSS 三十天利用概率 0.32%，处于第 25 百分位；未列入 CISA KEV；公开来源中尚无可用 POC。也就是说，这是一个”理论影响极大、当下还没人打”的洞。
实际风险取决于三件事同时成立：某个服务用 ZipStreamReader 解压不可信来源的包；解压目标目录下的文件可被覆盖后影响服务行为；覆盖路径能跳出预期目录。批量导入、主题与插件安装、备份还原、CI 里的制品解包，都是这类组合的常见发生地。CWE 分类给出的是 CWE-20（输入验证不当）加 CWE-436（解释冲突），后者正好描述了这类”两个组件对同一份数据理解不同”的缺陷。
修复与自查
- 升级到 9.0.5。对应提交为
8068ab480ccf8daa7411424e365fcdbe6d09443e，从 git 直接依赖的项目需要更新 rev。 - 确认依赖树里到底是谁在用。zip 常作为间接依赖被引入（打包工具、文档转换、备份组件）。检查
Cargo.lock中zip的版本，注意 9.x 之前用的是zip 0.x系列版本号，两套编号容易看漏。 - 不要用同一份包做”检查 + 使用”。这是本漏洞的核心教训：如果安全检查读中央目录、实际解压读本地文件头，两者之间任何差异都会被利用。要么只用一个解析器完成列举与解压，要么在解压后重新对落盘路径做一次白名单校验。
- 落盘前统一做规范化校验：拒绝绝对路径、拒绝含
..的条目、拒绝符号链接条目，最后再用canonicalize确认目标路径仍在解压根目录之内。
// 落盘前的路径校验思路（示意）
let root = std::fs::canonicalize(dest_root)?;
let target = root.join(entry_name);
let parent = std::fs::canonicalize(target.parent().unwrap())?;
if !parent.starts_with(&root) {
return Err("path escape blocked");
}另外，这类”检查与使用分离”的缺陷不止 zip 一处。上传校验里先看扩展名、后按魔数解析，WAF 里先按 Content-Type 放行、后端按内容解包，都属于同一个家族：只要两个组件的判断依据不同，攻击者就能制造出一个对其中一个”看起来正常”的输入。CWE-436 这个分类的价值就在于提醒审计时去找这类成对的解析路径，而不是只盯着单点校验。
顺带提一句同期披露的同类问题：Fortinet FortiSandbox 的 CVE-2026-107656（认证绕过，CVSS 3.1 9.8）、Mautic 的 CVE-2026-115188（认证用户任意文件上传）、Burrito 的 CVE-2026-102649（webhook 密钥为空时可伪造事件触发 Terraform 计划）、NexoPOS 的 CVE-2026-107092（api/update 目录遍历），都集中在十月中下旬披露。这一批的共同点是入口都不起眼，但都能一步踩到凭据或文件系统。