7-Zip LZX 堆溢出：特制 CAB 触发远程代码执行（CVE-2026-125742）
7-Zip 的 LZX 解码器存在堆溢出，特制的多卷 CAB 在解压时可执行代码；已在 26.06 中修复。
TL;DR
- 7-Zip 的 LZX 解码器存在越界堆写入，受害者解压特制的多卷 CAB 时会执行代码。LZX 窗口可在卷之间缩小，而解码器仍保留过期的写入偏移。
- 7-Zip 26.06 之前的所有版本受影响。缺陷位于解码器，因此共用该代码的 Windows、Linux 和 macOS 构建均受影响。
- CVE 记录将其评为 CVSS v4.0 8.5 High，CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N，CWE-787。目前没有已知的在野利用，截至 2026 年 11 月 10 日，CVE-2026-125742 不在 CISA 的 Known Exploited Vulnerabilities（KEV）目录中。
- 升级到 2026 年 11 月 6 日发布的 7-Zip 26.06，并在每一份副本更新前不要解压不可信的多卷 CAB。参见“如何修复？”。
我受影响吗？
以下条件必须全部成立：
- 你运行的是 26.06 之前的 7-Zip。CVE 记录给出的受影响范围是 26.06 之前的全部版本。
- 攻击者能让你用 7-Zip 解压特制的多卷 CAB，例如通过电子邮件、文件共享或下载。
- 解压使用 7-Zip 自带的 LZX 解码器，这是 LZX 压缩 CAB 文件夹的默认路径。其他压缩工具可能包含不同的代码。
CVE 记录将版本范围写为“0”至“26.06”（不含）。修复包含在 26.06 源码和 2026 年 11 月 6 日发布的 26.06 版本中。缺陷位于 CPP/7zip/Compress/LzxDecoder.cpp，官方构建共用这份代码。
| 分支 | 受影响版本 | 修复版本 |
|---|---|---|
| Windows、Linux 和 macOS 版 7-Zip | 26.06 之前的全部版本 | 26.06 |
在终端检查已安装版本：
7zz i | head -n 3
在 Windows 上，控制台可执行文件是 7z，因此在 PowerShell 或命令提示符中运行 7z i；图形界面可在“帮助”的“关于 7-Zip”中查看版本。官方 Linux 和 macOS 构建安装的是 7zz。Chocolatey 和 Windows Package Manager 会报告已安装的包：
choco list 7zip
winget list 7zip.7zip
如果版本行显示 26.05 或更早，该安装受影响。26.06 安装已修复此 CVE。
如何修复？
在每一台解压不可信归档的机器上升级到 7-Zip 26.06。
- 在 Windows 上，从官方下载页面安装 26.06，或使用包管理器：
winget upgrade 7zip.7zipchoco upgrade 7zip -y - 在 Linux 上，如果发行版提供 26.06，使用其软件包。如果没有，从 7-zip.org 安装官方 Linux 构建。用
7zz i确认版本。 - 在 macOS 上，从官方下载页面安装 26.06 的 macOS 构建，并用
7zz i确认版本。 - 检查自带 7-Zip 副本的软件，例如安装程序和归档管理器。更新系统 7-Zip 不会更新自带的副本。
没有哪个配置开关能在保留 CAB 解压的同时关闭有漏洞的 LZX 路径。在每一份副本更新前，把多卷 CAB 当作不可信代码：
- 不要解压通过电子邮件或不可信下载获得的 CAB 归档。
- 如果必须检查，请在一次性虚拟机或容器中以非特权用户解压。
- 在邮件网关阻止多卷 CAB 附件。这能降低暴露，但不能修复解码器。
根本原因是什么？
解码器为其 LZX 窗口维护写入位置 _pos，在继续多卷归档时只在窗口边界重置该位置。后续卷可以要求更小的窗口，而调整大小会释放旧缓冲区，却不重置 _pos。
以下是 7-Zip 26.05 中 Code_WithExceedReadWrite() 的有漏洞的继续逻辑：
if (!_keepHistory)
{
_pos = 0;
_overDict = false;
}
else if (_pos == _winSize)
{
_pos = 0;
_overDict = true;
}
_writePos = _pos;
_unpackedData = _win + _pos;
if (outSize > _winSize - _pos)
return S_FALSE;
当解码器在下一个 cabinet 中继续时，_keepHistory 为真。_pos 是当前写入偏移，_winSize 是当前窗口大小，_win 是窗口缓冲区。新归档会把 _pos 归零。继续时，只有当它恰好等于 _winSize 才归零。
调整大小发生在 Set_DictBits_and_Alloc() 中：
const UInt32 newWinSize = (UInt32)1 << numDictBits;
if (_needAlloc)
{
if (!_win || newWinSize != _winSize)
{
z7_AlignedFree(_win);
_winSize = 0;
const size_t alloc_size = newWinSize + k_OutBufSize_Add;
_win = (Byte *)z7_AlignedAlloc(alloc_size);
if (!_win)
return E_OUTOFMEMORY;
memset(_win, 0, alloc_size);
}
}
_winSize = newWinSize;
该函数释放旧窗口，分配更小的窗口，然后更新 _winSize。它没有改动 _pos。因此，以 2 MB 窗口压缩的第一个卷可以把 _pos 推进到远超后续卷声明的 32 KB 窗口。继续卷到达时，_pos 仍保存较大的偏移。
边界检查是有漏洞代码片段的最后一行。outSize 和 _winSize 是无符号数，而 _pos 大于 _winSize。减法 _winSize - _pos 回绕成一个巨大的值，因此检查通过。解码器随后写入 _win + _pos，大约越过 32 KB 缓冲区开头 1.3 MB。
如何被利用？
一对特制 CAB 卷让解码器经过大窗口，缩小窗口，然后送入一个在过期偏移处解码的继续块。
- 攻击者发送
v1.cab和v2.cab。受害者用 7-Zip 解压v1.cab。 v1.cab包含用大 LZX 窗口压缩的文件夹。一个文件夹把_pos推进到选定偏移，另一个文件夹把 shell 脚本写到磁盘。- 一个空文件夹声明 32 KB 窗口。解码器释放 2 MB 缓冲区，分配 32 KB 缓冲区并更新
_winSize，但_pos保留旧的大值。 v1.cab以指向v2.cab的继续指针结束。7-Zip 打开第二个卷，并在_keepHistory仍为真时把压缩块交给 LZX 解码器。- 边界检查下溢，解码器写入
_win + _pos，越过 32 KB 分配。 - 利用程序通过堆布局把
COutFileStream对象放在该偏移处。越界写入覆盖其 vtable 指针和类似 FILE 的字段。 - 通过损坏流的下一次写入会分派到偏移后的 glibc FILE vtable。这会导致
_IO_file_xsputn把对象当作FILE *，覆盖真正的标准输入结构，House of Apple 2 技术把它变成对system("sh r")的调用。第一个卷写入的脚本已在磁盘上，攻击者获得反向 shell。
研究者在 Arch Linux x86-64、glibc 2.44 上针对 7-Zip 26.04 和 26.05 测试了该链。文章描述了完整的利用链。
文章包含一种无需单独泄露、从堆 arena 指针组装 libc 地址的方法，并报告某个变体在重试下的成功率约为 30%。偏移取决于 7-Zip 版本、glibc 构建和堆布局。公开演示是 Linux，文章没有演示 Windows 利用链。
目前没有已知的在野利用。CVE 记录和研究者的文章是仅有的公开报告，二者都没有指明受害者或攻击活动。
攻击如何展开？
第一个 CAB 卷在大窗口下推进 LZX 写入位置。后续卷缩小窗口却不重置该位置，继续解码便写到新缓冲区之外。利用程序把这次写入变成代码执行。
攻击者能做什么？
让受害者解压特制归档的攻击者，会以运行 7-Zip 的用户权限执行代码。文章演示了 Linux 上的反向 shell。影响取决于该用户的权限和机器。
条件也是影响的一部分：
- 受害者必须用受影响的 7-Zip 构建解压第一个卷。在文件管理器中打开归档并列出内容不是已演示的触发方式；利用程序在解压期间运行。
- 攻击者必须投递两个卷。第二个卷会作为继续卷自动打开。
- 利用程序针对特定的 7-Zip、glibc 和堆布局进行校准。不同构建可能需要新的偏移，公开演示覆盖 Linux x86-64。
- 代码以启动 7-Zip 的用户身份运行。普通用户会暴露该用户的文件与会话。管理员解压则给攻击者管理员权限的代码执行。
- 没有已知的在野利用，也没有公开的受害者报告。
文章自己的数字说明了可靠性。关闭 ASLR 时 5 次全部成功；开启 ASLR 时某个变体 64 次中成功 19 次（约 30%）。失败会以解压错误结束，因此可以免费重试。这是可用的利用，不是必然成功的利用。
为什么修复有效？
修复在解码器分配新窗口时重置写入位置和历史标志，并在构造函数中初始化这两个字段。这消除了边界检查未能捕获的过期偏移。
以下是提交 d3296e39e1f1f92c7b41c0c3848e65640428d42d 的修复：
CDecoder::CDecoder() throw():
+ _pos(0),
_win(NULL),
+ _overDict(false),
_isUncompressedBlock(false),
@@
z7_AlignedFree
(_win);
_winSize = 0;
+ _pos = 0;
+ _overDict = false;
const size_t alloc_size = newWinSize + k_OutBufSize_Add;
_win = (Byte *)
Set_DictBits_and_Alloc() 现在在释放旧缓冲区的同一代码块中清除 _pos 和 _overDict。窗口缩小时，继续解码从新缓冲区的偏移 0 开始，无符号减法不再回绕。构造函数中的初始化还消除了首次分配时未初始化值的情况。
该改动关闭了已演示的路径。它不改变归档格式或解码器输出，因此普通的多卷 CAB 解压仍然可用。26.06 的发布说明只说“修复了一些错误和漏洞”；该提交是这个 CVE 的具体修复。
如何检查是否已遭入侵？
CVE 记录和研究者都没有公开入侵指标。利用程序会留下一个 shell 脚本并建立网络连接，因此应查找这些影响，而不是签名。
- 查找 CAB 解压期间出现的异常文件，特别是一个小型 shell 脚本和大量小型填充文件。演示链写入名为
r的脚本，并用许多填充文件布置堆。 - 检查解压时间前后机器的出站连接，尤其是来自
7z、7zFM或它们启动的 shell 的连接。 - 查找一起投递的 CAB 文件对，其中第一个指向继续卷。来自不可信来源的多卷 CAB 就是投递模式。
- 在解压过不可信 CAB 的主机上，清理前保留解压目录以及进程和网络日志。如果无法排除代码执行，重建主机。
失败的尝试可能只留下解压错误，没有其他痕迹。没有 shell 或连接并不证明归档无害。
时间线
- 2026-11-06：7-Zip 26.06 发布，包含提交
d3296e39e1f1f92c7b41c0c3848e65640428d42d，在分配窗口时重置_pos和_overDict。 - 2026-11-10 11:57 UTC：VulnCheck 预留 CVE-2026-125742。
- 2026-11-10 12:00 UTC：VulnCheck 发布 CVE 记录及其公告。
- 2026-11-10：Nguyễn Trần Thanh Lâm 发布技术文章和利用演示。
常见问题
CVE-2026-125742 在野被利用了吗？
没有已知利用。CVE 记录、VulnCheck 公告和研究者的文章描述的是可用的概念验证，不是攻击。截至 2026 年 11 月 10 日，该 CVE 不在 CISA 的 Known Exploited Vulnerabilities 目录中。
有公开的利用代码吗？
有，一篇公开技术文章描述了完整利用链并包含演示视频。它没有链接利用代码仓库。CVE 记录把该文章标记为利用参考，文章报告了实测成功率。
该缺陷影响 Windows、Linux 和 macOS 上的 7-Zip 吗？
有漏洞的解码器是共享源码。公开演示运行在 Linux x86-64 上，文章说偏移需要针对每个 7-Zip、glibc 和堆布局进行校准。Windows 使用不同的 C 运行时，因此确切的 glibc 链不能直接移植，但解码器中的越界写入仍然存在。请更新每个平台。
打开归档就会触发，还是只有解压才会？
已演示的触发方式是解压。解码器在写入解压文件时处理继续卷。列出归档内容是另一条路径，未被演示为触发方式。
7-Zip 26.06 安全吗？
对这个 CVE 是安全的。26.06 包含修复提交，是 CVE 记录指定的修复版本。请单独检查自带副本，因为自带 7-Zip 代码的应用不会因安装 26.06 而更新。
如果无法立即更新怎么办？
不要解压来自不可信来源的多卷 CAB，并在邮件网关阻止它们。如果必须检查，请在一次性虚拟机或容器中以非特权用户操作。这些措施降低暴露，但不修复解码器。
参考文献
- CVE-2026-125742 记录，CNA 为 VulnCheck，2026 年 11 月 10 日发布，包含 CVSS v4.0 8.5 和 v3.1 7.8 向量、CWE-787 以及 26.06 之前的受影响范围：https://www.cve.org/CVERecord?id=CVE-2026-125742（2026 年 11 月 10 日检查）
- VulnCheck 公告“7-Zip before 26.06 Heap Out-of-Bounds Write via LZX Decoder in CAB Extraction”，2026 年 11 月 10 日，致谢 Nanyang Technological University 的 Nguyễn Trần Thanh Lâm：https://www.vulncheck.com/advisories/7-zip-before-26.06-heap-out-of-bounds-write-via-lzx-decoder-in-cab-extraction（2026 年 11 月 10 日检查）
- 7-Zip 提交
d3296e39e1f1f92c7b41c0c3848e65640428d42d，在Set_DictBits_and_Alloc()中重置_pos和_overDict的修复：https://github.com/ip7z/7zip/commit/d3296e39e1f1f92c7b41c0c3848e65640428d42d（2026 年 11 月 10 日检查） - 7-Zip 26.06 版本，厂商标注为 2026 年 11 月 6 日（GitHub 发布对象创建于 11 月 7 日）：https://github.com/ip7z/7zip/releases/tag/26.06（2026 年 11 月 10 日检查）
- 有漏洞的
Code_WithExceedReadWrite()和Set_DictBits_and_Alloc()（标签 26.05 的CPP/7zip/Compress/LzxDecoder.cpp）：https://github.com/ip7z/7zip/blob/26.05/CPP/7zip/Compress/LzxDecoder.cpp#L1444-L1513（2026 年 11 月 10 日检查） - Nguyễn Trần Thanh Lâm，“7-Zip Cabinet Window Desync: From Heap OOB Write to Remote Code Execution”，2026 年 11 月 10 日，根本原因分析、利用链和实测成功率：https://potion-brew.pages.dev/posts/7zip-cab-lzx-window-desync-rce（2026 年 11 月 10 日检查）
- Chocolatey 的 7zip 社区包页面，总下载量 35,677,761，版本 26.6.0 下载量 6,087，2026 年 11 月 10 日检查：https://community.chocolatey.org/packages/7zip（2026 年 11 月 10 日检查）
- CISA Known Exploited Vulnerabilities 目录 JSON 源，2026 年 11 月 10 日检查 CVE-2026-125742 无匹配：https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json（2026 年 11 月 10 日检查）