1字节怎么 吞掉256MB

CVE-2026-48095

1字节怎么 吞掉256MB

7-Zip高危漏洞攻击链全解析

你给程序申请了1字节的房间，它往里塞了256MB的数据。

这不是段子。1字节的缓冲区，怎么吞下256MB？更关键的是——这256MB的洪水漫出去之后，到底冲毁了什么？

这是刚被确认的CVE-2026-48095，一个影响7-Zip 26.00及更早版本的高危漏洞，CVSS评分8.8（部分评估为8.1）。你的电脑上大概率装着7-Zip。

STEP 01

一个"未定义"的移位， 把房间面积算成了0

一切从7-Zip解析NTFS文件系统的一段代码开始。

7-Zip在处理NTFS压缩文件时，需要计算"压缩单元"的大小。代码长这样：

(UInt32)1 << (BlockSizeLog + CompressionUnit)

翻译成人话：把1往左移若干位，相当于算2的N次方——算出这个压缩单元需要多大的缓冲区。

问题出在"若干位"上。攻击者可以构造一个恶意的NTFS镜像，让 ClusterSizeLog ≥ 28 且 CompressionUnit = 4，移位次数达到32次。而对一个32位整数左移32位，在C++标准里是未定义行为——编译器爱怎么处理就怎么处理。

在x86处理器上，移位指令会直接取移位数的低5位，32变成0。于是1左移0位，还是1。程序算出来：这个压缩单元只需要1字节的缓冲区。

就像你用计算器算房间面积，按错了一步，把120平米算成了0.001平米——然后你就按这个数字去买家具。

STEP 02

1字节的门被撞开， 洪水冲进了隔壁的控制室

缓冲区只分了1字节，但程序接下来要往里面写入多少数据？

1 字节

→

256MB

这是NTFS压缩单元的理论上限。程序调用 ReadStream_FALSE，把攻击者精心构造的数据往那1字节的缓冲区里灌。1字节的门，256MB的洪水——结果可想而知：数据漫出去了。

漫出去的水冲到了哪里？这才是关键。

在内存中，_inBuf（那1字节的缓冲区）和 CInStream 对象紧挨着。CInStream对象里存着一个虚函数表指针——你可以把它理解为程序运行时的"指令手册"，告诉程序下一步该跳到哪里执行代码。这个指针距离 _inBuf 只有304字节。

也就是说，洪水刚漫出去不到1KB，就淹没了这本指令手册。

想象一栋楼：1平米的房间，搬家公司还是按整栋楼的量往里搬——家具从门里溢出来，冲进了隔壁放调度指令的控制室。

STEP 03

偷换指令手册， 整栋楼归你了

洪水淹没了指令手册——然后呢？攻击者不需要破门，只需要换一本手册。

虚函数表指针被覆盖之后，发生了什么？

程序下一次通过虚表调用函数时，跳转地址已经不再是原来的合法代码，而是攻击者指定的地址。攻击者通过控制溢出数据的内容，精确地往虚表指针的位置写入了自己想要的地址——程序乖乖跳过去，开始执行攻击者的代码。

这就是"任意代码执行"：攻击者可以在你的电脑上跑任何程序。装后门、偷数据、加密勒索——随他选。

⚠️ 前提条件

在64位系统上，漏洞链完整走向代码执行还需要目标机器至少有16GB内存。因为攻击链中有一步需要分配8GB的缓冲区，内存不够的话，这一步会失败，漏洞"只"能造成拒绝服务——程序崩溃，但不会被接管。注意，"只"是加引号的。你的7-Zip崩溃了，你大概率只会觉得"这软件怎么又崩了"，不会意识到刚才有人试图接管你的电脑。

三步走完，一条完整的攻击链成型了：

移位溢出

→

堆溢出

→

虚表劫持

但这条攻击链最让人后怕的，还不是技术本身。

你甚至不需要解压

7-Zip判断文件类型，不看后缀名。

它靠的是文件偏移量第3个字节位置的NTFS特征码。这意味着一个恶意文件可以伪装成 .zip、.rar、.7z，甚至没有任何后缀——只要7-Zip打开它，就会自动调用存在漏洞的NTFS解析模块。

更离谱的是，奇安信的研究还发现了一个"双重处理"的设计缺陷：即使文件后缀名对应的格式处理器先拒绝了这个文件，NTFS处理器仍然会被触发。前门拒了，后门还开着。

你收到一个看起来普通的压缩包，双击用7-Zip打开——不需要解压，不需要点任何按钮——恶意代码已经在运行了。

更让人不安的是——

7-Zip的下载量超过4亿次，受影响的设备可能达数亿台。不只是你电脑上那个7-Zip：杀毒软件内嵌7-Zip库来扫描压缩包，备份工具用它做压缩，日志分析软件处理压缩的日志文件，文件管理器集成它的功能——这些程序往往以高权限运行，且无需你手动操作就会自动接触压缩文件。它们中的7-Zip库如果没更新，同样是一条敞开的通道。

服务器端也不安全。Ubuntu 24/26、RHEL 8均携带受影响版本的7-Zip，大量Docker镜像和OEM预装系统也未能幸免。CI/CD管线里跑着的 7z 命令，如果处理了来自外部的压缩文件，同样可能被利用。Python概念验证脚本（PoC）已经公开，攻击利用的门槛正在降低。

而修复版本26.01，4月27日就发布了。从漏洞报告到修复，只用了3天——开源社区的响应速度值得点赞。但7-Zip没有自动更新机制，修复完全依赖用户手动升级或包管理器推送。一个多月过去了，你升级了吗？你公司的CI/CD管线升级了吗？

现在就做

普通用户

一件事就够了：把7-Zip升级到26.01。打开7-Zip，菜单栏点"帮助"→"关于7-Zip"，看一眼版本号。不是26.01的，去 7-zip.org 下载最新版。

IT从业者

还需要多查几处：

CI/CD管线：检查自动化流程中调用的 7z 命令，确认所在环境的7-Zip版本。容器镜像里预装的7-Zip尤其容易被遗忘。

内嵌7-Zip库的软件：杀毒软件、备份工具、文件管理器——检查它们是否打包了自己的7-Zip库，以及是否已经更新。

Linux服务器：Ubuntu 24/26、RHEL 8的默认仓库版本可能仍在受影响范围内，确认包管理器推送的版本是否已修补。

这个漏洞最耐人寻味的地方，不是1字节怎么吞掉256MB——虽然这确实足够戏剧性。而是3天就能修好的漏洞，可能要花3个月才能让大多数人知道它的存在。

开源社区修得够快。 但"修了"不等于"安全了"。 中间那道鸿沟，只能靠我们自己迈过去。