
安全研究人员在广泛使用的LZ4压缩算法Java库lz4-java中发现一个高危漏洞(CVE-2025-66566),其CVSS评分为8.2分,对数据机密性构成重大威胁。该漏洞可使攻击者诱骗解压缩器读取并暴露未初始化的内存,可能泄露先前操作残留的敏感数据。
漏洞原理
该漏洞的核心问题在于库处理解压缩过程中输出缓冲区的方式。安全公告指出:"lz4-java 1.10.0及更早版本中,基于Java的解压缩器实现未充分清除输出缓冲区,远程攻击者可通过特制的压缩输入读取先前缓冲区内容"。
LZ4算法为追求速度,通常会重复使用已解压的数据。但该逻辑的Java实现存在关键盲区:攻击者提供特制输入帧时,"可能诱导Java实现从输出缓冲区中尚未包含解压数据的区域进行复制"。
风险场景
若应用程序为节省内存而重用输出缓冲区(常见的性能优化手段),这些缓冲区的"脏"区域可能仍保留着前次会话的密码、加密密钥或用户数据。公告警告称:"若该区域因解压前未清除输出缓冲区而包含敏感信息,这些数据将被复制到解压输出中"。
受影响范围
并非所有lz4-java实现都受影响。公告明确指出"基于JNI的实现不受影响",但判断应用程序是否安全需仔细检查所调用的工厂方法:
- 纯Java实现:LZ4Factory.safeInstance()和LZ4Factory.unsafeInstance()均受影响
- "最快"陷阱:使用LZ4Factory.fastestInstance()的开发者可能误以为在使用安全的原生代码,但当平台不受支持且无法使用JNI时,会回退至存在漏洞的Java实现
- "快速"解压器:LZ4Factory.nativeInstance().fastDecompressor()自1.8.1版本起就存在漏洞,因其使用了不安全的safeInstance()逻辑
缓解措施
漏洞严重性取决于具体使用场景:"每次分配新目标缓冲区或仅使用归零缓冲区的用户不受影响"。但对循环利用内存的高性能应用而言风险极高。
维护者已发布补丁:"lz4-java 1.10.1修复了此问题,无需更改用户代码"。若无法立即升级,开发者可手动缓解威胁:"若无法升级至1.10.1,可在将输出缓冲区传递给解压函数前将其归零"。
139

被折叠的 条评论
为什么被折叠?



