文章总结： 文章报道了AI代理KimiK3在约90分钟内发现19个Redis零日漏洞，并在27分钟内为Redis8.8.0构造完整RCE利用链。漏洞涉及restore命令触发的streams双重释放和redisbloom模块tdigest越界写入，可导致远程代码执行。Redis官方已发布安全更新（6.2.23/7.2.15/7.4.10/8.2.8/8.4.5/8.6.5/8.8.1），建议立即升级并禁用restore命令。目前漏洞尚未分配CVE编号。 综合评分： 89 文章分类： 漏洞分析,漏洞预警,安全工具,红队,web安全

AI代理90分钟挖出19个Redis零日？Kimi K3再曝RCE利用链

看雪学苑 看雪学苑

看雪学苑

2026年7月24日 17:59 上海

在小说阅读器读本章

去阅读

7月23日，Redis官方紧急发布了7个安全更新，覆盖多个主流分支版本。而迫使这次“连夜抢修”的，正是研究团队 Bera Buddies 与研究员 Chaofan Shou 所披露的成果——他们声称，其使用的 AI 代理Kimi K3 在自动化漏洞挖掘中，仅用约 90 分钟就发现了 19 个 Redis 零日漏洞，并在另一轮运行中，仅 27 分钟就为 Redis 8.8.0 构造了完整的 RCE 利用。

无论这些惊人的数字最终能被复现到何种程度，Redis 官方已经确认了漏洞与修复，并且公开的 PoC 完整演示了如何从认证用户权限一路打穿至系统命令执行。所有 Redis 用户都应高度警惕。

01

致命入口：RESTORE 命令

这两套攻击链背后，存在一个共同的“命门”——RESTORE 命令。攻击者只要拥有该命令的执行权限，就能向 Redis 注入恶意构造的 RDB 数据，触发底层内存破坏。

路径一指向 Redis Streams 的共享 NACK 机制，需要 RESTORE、EVAL 和 XGROUP 权限。

路径二 指向 RedisBloom 模块的 TDigest 加载器，需要 RESTORE、EVAL 和已加载的 RedisBloom 模块。

两条路径最终都实现了以 Redis 进程身份执行系统命令，手法极其老练。

01

路径一：Streams 双重释放漏洞

该漏洞源于 Streams 消费者对同一条待处理记录的共享所有权问题。

具体而言，一份经过刻意篡改的 RDB 文件，能让两个消费者指向同一个 streamNACK 内部结构。当 Redis 移除第一个消费者时，该 streamNACK 被正常释放，但第二个消费者仍保留着悬空指针。一旦第二个消费者也被移除，就会对同一块内存区域执行双重释放。

公开的利用脚本正是将这种双重释放转化为任意内存读写能力，随后对数据库哈希函数投毒，最终只需触发一次看似普通的 GET 命令，即可调用 system() 实现 RCE。

值得注意的一个插曲：Redis 8.6.4 的发布说明曾声称已修复此问题，但经过源码审查，该版本的标签源码中实际并未包含重复所有权的安全检查。真正的修复代码直到 7 月 23 日发布的 Redis 8.6.5 才正式入版。如果你正运行在 8.6.4，必须立即升级。

02

路径二：RedisBloom 模块 TDigest 越界写入

第二个漏洞藏身于 RedisBloom 模块的 TDigest RDB 加载器。其根本原因在于“信任”了攻击者提供的容量字段。

加载器在分配存放 centroid 数组的内存时，依据的是序列化后的压缩值；但在决定加载多少数据时，却采用了攻击者可单独控制的容量字段。当攻击者将容量字段构造得极大，而实际分配的内存又极小，就会产生越界写入。

针对 Redis 8.8.0 的 PoC 将这一越界写逐步拓展为稳定的读/写原语，进而泄露 Redis 与 libc 的基地址，最后同样通过毒化哈希函数，使特定的 GET 请求触发 system() 执行。另一个独立公开的 PoC 也基于相同根因，给出了认证后的 RCE 链。

Redis 的修复措施是强制要求加载的 TDigest 容量与根据压缩值派生的实际分配相匹配，并在读取数组之前对相关计数器进行边界检查。

02

修复版本速查

Redis 按分支一次性交付了修复，请根据你所在的分支升级至明确的安全版本：

• Redis 6.2.23、7.2.15、7.4.10

修复了 Streams 共享 NACK 的 use-after-free 漏洞。

• Redis 8.2.8、8.4.5、8.6.5

同时修复了 Streams 漏洞与 RedisBloom / TDigest 越界写入。

• Redis 8.8.1

修复了 RedisBloom 和 TDigest 加载器问题；Streams 的保护代码在 8.8.0 中已存在。

今年五月 Redis 曾建议用户升级到的 6.2.22 和 7.4.9，并未包含此次 Streams 的所有权保护，这两版同样是本次 PoC 的目标。不要仅仅以“最近打过补丁”来判断安全，务必检查准确的分支版本号。

03

无新 CVE？争议与现状

截至 7 月 24 日，此次修复的漏洞均未被分配新的 CVE 编号，Redis 的发布说明中也未提供 CVSS 评分。

在漏洞披露仓库中，Streams 漏洞被标记为 “CVE-2026-25589 不完整修复家族” 的一部分，但 Redis 官方对该 CVE 的原始映射仅为“RedisBloom RESTORE 时的内存破坏”，而非本次 Streams 共享 NACK 问题。NVD 和 CISA 已知利用漏洞目录中，也暂无针对这两个漏洞的条目。

这一“无号”状态可能会延缓部分自动化扫描工具的识别，请勿仅以 CVE 编号作为修补的唯一依据。

此次披露的另一大爆点，无疑是Kimi K3 代理的角色。研究方自称其身份为 “AI Agent Research”，并宣称 AI 在约 90 分钟内找出了 19 个 Redis 零日，再花 27 分钟生成了针对 8.8.0 的完整利用。

Redis 官方仅确认了漏洞与修复，并未对发现的零日总数或 AI 的独立自主程度做出验证。但这些成果至少已经说明，AI 在模糊测试、数据流分析和漏洞利用自动化方面的实际能力，正在以前所未有的速度逼近实用化的红线。对于防守方而言，依赖“人工挖洞”的时代窗口，恐怕正加速关闭。

04

安全建议

1. 立即升级至对应分支的最新安全版本（6.2.23、7.2.15、7.4.10、8.2.8、8.4.5、8.6.5 或 8.8.1）。

2. 收回 RESTORE 权限：对不严格需要的所有账户禁用 RESTORE 命令，可直接切断目前公开的两条利用路径。

3. 封锁不信任的网络访问：即便需要 RESTORE，也应仅限受信内网或管理网段访问，并配合强认证。

4. 验证实际版本：即便近期执行过升级，也必须核对 redis-server --version 输出的完整版本号，而非仅凭“安全更新已完成”的假设。

资讯来源：The Hacker News、Redis 官方安全公告

球分享

球点赞

球在看

免责声明：

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

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

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

本文转载自：看雪学苑 看雪学苑 看雪学苑《AI代理90分钟挖出19个Redis零日？Kimi K3再曝RCE利用链》