研究人员称 Kimi K3 智能体发现 Redis 零日漏洞并构建远程代码执行利用

导语：研究人员宣称，由 Kimi K3 智能体在受控环境中自主发现并构造出针对 Redis 多版本原版的认证远程代码执行利用链，相关 PoC 已公开发布，触发 Redis 在 7 月 23 日集中发布七个安全更新。

Redis 于 7 月 23 日发布了七个安全更新，原因是研究人员公开了针对 Redis 6.2.22、7.4.9、8.6.4 和 8.8.0 原版的认证 RCE 概念验证利用代码。所有四条利用链都需要 RESTORE 命令；Streams 利用链还需要 EVAL 与 XGROUP；8.8.0 利用链需要 EVAL 以及内置的 RedisBloom 模块。Redis 表示，底层内存缺陷可能导致远程代码执行。

按分支划分的修复版本如下：Redis 6.2.23、7.2.15 与 7.4.10 修复了 Streams 共享 NACK 释放后使用漏洞；Redis 8.2.8、8.4.5 与 8.6.5 同时修复 Streams 问题以及 RedisBloom 与 TDigest 越界写入漏洞；Redis 8.8.1 修复了 RedisBloom 与 TDigest 加载器，而 Streams 防护逻辑在 Redis 8.8.0 中已经存在。

两组被公开概念验证的 Redis 6.2.22 与 7.4.9，正是 Redis 在 5 月份建议用户安装的安全更新版本，但这些发布版本并未包含共享 NACK 所有权防护。建议立即升级至所部署分支对应的修复版本；在升级之前，从并不严格需要的账户中撤销 RESTORE 权限，并阻断不可信的网络访问。限制 RESTORE 可同时切断两条已公开的攻击路径。

截至 2026 年 7 月 24 日，无论是 Redis 在 7 月 23 日发布的更新说明，还是研究人员公开的概念验证仓库，均未报告在野利用行为。

第一条路径位于 Redis Streams 中，是一个共享所有权缺陷。损坏的 RDB 对象可以让两个消费者指向同一条待确认（pending）条目记录，其内部表示为 streamNACK。移除第一个消费者会释放该对象，并使第二个消费者持有悬空指针；随后的脚本会再移除第二个消费者，从而对同一内存块连续释放两次，构成双重释放漏洞。该公开脚本的作用就是将这种内存破坏转化为任意内存访问，最终调用 system() 执行任意命令。

Redis 8.6.4 的发布说明引用了 PR #15081。但 The Hacker News 经过源代码审查发现，打标签的 8.6.4 源码中缺少该补丁所加入的重复所有权检查。该防护逻辑出现在 7 月 23 日发布的 Redis 8.6.5 中。公开的 Redis 8.6.4 脚本可将该双重释放转化为任意内存访问，并进一步污染数据库哈希函数，使得精心构造的 GET 请求触发 system()，脚本执行后会恢复原指针，并检查 Redis 是否仍然正常响应。

第二条路径位于 RedisBloom 的 TDigest RDB 加载器中，加载器依据一个序列化压缩值分配质心数组内存，却在决定可加载节点数量时信任了另一个由攻击者控制的容量字段。较小的真实分配配合夸大的元数据即可造成越界写入。Redis 8.8.0 脚本将该越界写入转化为读写原语，泄漏 Redis 与 libc 的地址，并污染数据库哈希函数使精心构造的 GET 调用 system()。同日还发布了针对同一根因的另一个概念验证以及对 Redis 8.8.0 的认证 RCE 链。

Redis 在 7 月版本中的修复要求加载的 TDigest 容量必须与依据压缩值计算出的内存分配相匹配，同时在读取数组之前对已合并与未合并节点计数器进行边界检查。

公开的概念验证仓库将 Streams 问题归入 CVE-2026-25589 的“不完整修复族”，但 Redis 仍将 CVE-2026-25589 映射为 RESTORE 过程中 RedisBloom 的内存损坏问题，而非 Streams 的共享 NACK 缺陷。Redis 在 7 月发布说明中未列出这两类新缺陷的 CVE 编号或 CVSS 评分。截至 7 月 24 日，The Hacker News 在搜索中未发现 7 月公开的共享 NACK 或 TDigest 缺陷在 NVD 中有独立记录；NVD 仍仅列出 5 月份的 CVE-2026-25243 与 CVE-2026-25589 记录。对 CISA 已知被利用漏洞目录的检索亦未返回上述两个编号的条目。