Redis漏洞：AI代理Kimi K3 90分钟挖出19个零日并构造RCE利用链

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

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

致命入口：RESTORE 命令

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

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

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

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

路径一：Streams 双重释放漏洞

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

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

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

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

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

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

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

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

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

修复版本速查

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 的目标。不要仅仅以“最近打过补丁”来判断安全，务必检查准确的分支版本号。

无新 CVE？争议与现状

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

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

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

AI 代理的争议

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

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

安全建议

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 官方安全公告

更多技术话题讨论，欢迎前往 云栈社区 交流。