文章总结： 研究人员发现Redis多个版本存在零日漏洞，包括streams共享nack释放后使用和redisbloomtdigest越界写入，可导致远程代码执行。Redis已于7月23日发布修复版本。建议立即升级到修复版本，撤销非必要账户的restore权限，并阻止不受信任的网络访问。截至7月24日未发现实际利用。 综合评分： 85 文章分类： 漏洞分析,应急响应,解决方案,应用安全,漏洞预警

研究人员称：Kimi K3 Agents 发现了 Redis 零日漏洞并构建了远程代码执行漏洞利用程序

Rhinoer Rhinoer

犀牛安全

2026年7月24日 15:17 北京

在小说阅读器读本章

去阅读

在研究人员发布了针对标准 Redis 6.2.22、7.4.9、8.6.4 和 8.8.0 的经过认证的 RCE PoC 之后，Redis 于 7 月 23 日发布了七个安全版本。

所有四个链都需要 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 中已经存在。

两个 PoC 目标版本分别是 Redis 6.2.22 和 7.4.9，它们是 Redis 在 5 月份建议用户安装的安全更新版本，但这些版本并不包含共享 NACK 所有权保护。

请将已部署分支升级到修复版本。在此之前，请撤销非必要账户的 RESTORE 权限，并阻止不受信任的网络访问。限制 RESTORE 权限可以切断所有已公开的访问路径。

截至 2026 年 7 月 24 日， Redis 7 月 23 日发布的说明以及审查的公共 PoC 存储库均未报告实际利用情况。

两条恢复的路径

Redis Streams 路径存在共享所有权漏洞。损坏的 RDB 对象可能导致两个消费者指向同一个待处理条目记录，因此移除这两个消费者会释放同一个对象两次。

已发布的脚本旨在将由此产生的内存损坏转换为任意内存访问，并最终调用 system()。

RedisBloom 路径是 TDigest RDB 加载器中的越界写入。该加载器从一个序列化值分配内存，但在决定加载多少数据时，却信任了一个由攻击者控制的独立容量字段。

Redis 8.8.0 脚本旨在将这种不匹配转换为读写原语，泄露 Redis 和 libc 地址，并调用 system()。

• Streams 共享 NACK 链

第一条路径在 Redis Streams 中。一个损坏的 RDB 对象会导致两个消费者指向同一个待处理条目记录，内部用 streamNACK 表示。移除第一个消费者会释放该对象，但第二个消费者会持有悬空指针。脚本随后也会移除第二个消费者。一个代码块，两次释放。

Redis 8.6.4 的发布说明中引用了PR #15081。但 Hacker News 的源代码审查发现，带有此标签的 8.6.4 版本源代码缺少该更改添加的重复所有权检查。该保护机制已在7 月 23 日发布的Redis 8.6.5版本中得到修复。

已发布的 Redis 8.6.4 脚本旨在将双重释放操作转化为任意内存访问，然后篡改数据库哈希函数，使精心构造的 GET 请求调用 system() 函数。该脚本会恢复指针并检查 Redis 是否仍然响应。

• RedisBloom TDigest 链

第二条路径位于 RedisBloom TDigest RDB 加载器中。它根据序列化的压缩值分配质心数组，然后在决定可以加载多少个节点时，信任一个由攻击者控制的独立容量字段。少量实际分配的内存加上膨胀的元数据会导致越界写入。

Redis 8.8.0 脚本旨在将写入操作转换为读写原语，泄露 Redis 和 libc 地址，并篡改数据库哈希函数，从而使精心构造的 GET 请求调用 system() 函数。另一份概念验证报告也公布了相同的根本原因，并提供了一条针对 Redis 8.8.0 的已验证远程代码执行 (RCE) 链。

Redis七月份的修复程序要求已加载的 TDigest 容量必须与根据压缩值分配的容量相匹配。此外，在读取数组之前，它还会限制已合并和未合并节点的计数器。七张公告，无新增CVE记录

该代码库将 Streams 问题归类为 CVE-2026-25589“不完整修复系列”的一部分，但 Redis 将该 CVE 映射到 RESTORE 期间的 RedisBloom 内存损坏，而非 Streams 的共享 NACK 漏洞。Redis 7 月的发布说明中没有列出这两个新漏洞类别的 CVE 或 CVSS 评分。

截至7月24日，《黑客新闻》的搜索结果显示，NVD数据库中没有针对7月份共享NACK或TDigest漏洞的单独记录。NVD数据库仍然列出了5月份的CVE-2026-25243和CVE-2026-25589漏洞记录。对CISA的已知漏洞利用目录进行搜索，也未找到这两个漏洞的条目。

此次披露是在五月份修复了另一个由人工智能发现的 Redis 远程代码执行漏洞之后进行的。Bera Buddies自称是一家“人工智能代理研究公司”。Chaofan Shou在 X 论坛上表示，Kimi K3 代理在大约 90 分钟内发现了 19 个 Redis 零日漏洞，并称另一次运行在 27 分钟内发现了 Redis 8.8.0 的漏洞利用程序。

这些漏洞数量、发生时间以及声称的自主程度均由Redis自行报告。Redis的公开记录证实了这些缺陷及其修复情况，但并未验证其声称的零日漏洞数量或代理的独立运行程度。

5 月份的目标版本是 Redis 6.2.22 和 7.4.9。到了 7 月份，这两个版本都需要再次更新。请检查确切的分支版本，而不是 Redis 是否只是“最近打过补丁”。

信息来源：TheHackerNews

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：犀牛安全 Rhinoer Rhinoer《研究人员称：Kimi K3 Agents 发现了 Redis 零日漏洞并构建了远程代码执行漏洞利用程序》