Redis再曝高危RCE漏洞：CVE-2026-66373 RESTORE命令双重释放可致服务器沦陷
七月底，Redis社区又迎来了一则不太乐观的消息。编号为CVE-2026-66373的安全漏洞被正式披露，这个藏在 RESTORE 命令里的"老问题"，让不少运维团队捏了把汗。说白了，攻击者只要手里握着合法的 Redis 认证凭据，就能通过一串精心编排的 Stream 操作把服务器内存搞乱，最终拿到执行任意代码的权限。CVSS 给了 7.5 分，属于"高危"档，而且概念验证代码已经公开挂在 GitHub 上，留给管理员打补丁的时间并不宽裕。
漏洞概况：旧补丁没堵住的"后门"
先说说这个漏洞的来龙去脉。CVE-2026-66373 本质上是对CVE-2026-25243修复不彻底的"补丁绕过"。
今年五月初，Redis 修复了 CVE-2026-25243，那是个 RESTORE 命令在处理序列化数据时校验不严导致的内存损坏问题。当时补丁堵住了直接路径，但研发团队显然没注意到 Stream 消费者组（Consumer Group）里还有一个更隐蔽的共享引用场景。结果到了七月，安全研究人员发现：如果 RESTORE 恢复出来的 Stream 数据里，同一个 NACK（待处理条目）被同时挂到两个消费者名下，那么后续用XGROUP DELCONSUMER删掉这两个消费者时，Redis 会把这个 NACK 释放两次——这就是典型的双重释放（Double Free）。
MITRE 在 2026 年 7 月 25 日正式收录了这个漏洞，NVD 同步更新。阿里云漏洞库的分析指出，问题出在src/rdb.c的rdbLoadObject函数：恢复消费者 PEL（Pending Entries List）时，代码直接把同一个streamNACK指针写进了两个消费者的 PEL，却没检查这个 NACK 是不是已经被别人占用了。
攻击链是怎么串起来的
这个漏洞的利用门槛比想象中要高一些，但技术路径很清晰。
攻击者首先需要具备 RESTORE 命令的执行权限——这在生产环境里通常不会随便开放给普通应用账号，属于"不常见但存在"的授权场景。拿到权限后，攻击者构造一个畸形的 Stream RDB 负载，通过 RESTORE 灌进 Redis。这个负载会让两个消费者指向同一个 NACK 对象。
接下来，攻击者调用XGROUP DELCONSUMER把这两个消费者都删掉。第一次删除释放 NACK，第二次删除又释放同一个地址，堆内存立刻被破坏。此时配合 Lua 脚本（EVAL）做堆布局整形，就能把释放后的内存块重新占位，注入恶意代码，最终调用system()函数执行 shell 命令。
GitHub 上公开的 PoC 仓库berabuddies/redis-poc已经验证了这个利用链在多个版本上的可靠性：6.2.22 十次成功十次，7.4.9 五次成功五次，8.6.4 更是跑了二十五次无一失手。
影响面到底有多大
从版本覆盖来看，这个漏洞的打击面相当广。所有Redis 8.8.0 之前的官方版本都受影响，包括 6.2.x、7.2.x、7.4.x、8.2.x、8.4.x、8.6.x 各个分支，以及对应的 Docker 镜像（redis:6.2、redis:7.2、redis:7.4、redis:8.2、redis:8.4、redis:8.6）。
腾讯云安全团队也发了风险通告，把漏洞等级定为"高风险"。他们给出的受影响版本清单更细：Redis < 8.6.5、< 8.4.5、< 8.2.8、< 7.4.10、< 7.2.15、< 6.2.23，安全版本统一要求 >= 8.8.0。
不过好消息是，截至 2026 年 7 月底，还没有确认在野利用的案例。EPSS（漏洞利用预测评分系统）给出的 30 天被利用概率大约是 0.47% 到 0.5%，在所有 CVE 里排名中等偏下。 这倒不是说可以高枕无忧，而是因为利用需要认证权限和 RESTORE 命令这两个前置条件，攻击者想直接"盲打"公网 Redis 实例并不容易。
修复方案：升级是最稳妥的路
Redis 官方在 8.8.0 版本里彻底修掉了这个问题。修复 commit 是47c51369eeffd55e1baf20df7955a3dfbe842fc4，对应 PR #15081，由 Sergey Georgiev 合入。代码层面的改动很直接：在rdbLoadObject给每个消费者 PEL 写入 streamNACK 之前，加了一道if (nack->consumer != NULL)的守卫。如果发现这个 NACK 已经被分配给其他消费者，立刻调用rdbReportCorruptRDB报错，终止加载，从源头上阻断共享路径。
对于还没法立刻升级的团队，有几个权宜之计可以先用着：
第一，收紧 RESTORE 权限。通过 Redis ACL 把+restore从非管理员账号里撤掉。绝大多数业务应用根本用不着 RESTORE，禁掉它几乎零副作用。
第二，把 Redis 藏起来。绑到内网地址，别直接暴露在公网。配合防火墙规则，限制只有特定主机才能连上 6379 端口。
第三，监控异常命令。开启MONITOR或者命令日志，盯着点有没有来历不明的 RESTORE 调用。如果看到应用账号突然执行XGROUP DELCONSUMER后又跟着一串EVAL，那基本就是在试探。
第四，临时补丁。如果升级周期太长，可以手动 cherry-pick PR #15081 的改动到当前分支，阿里云漏洞库提到这个 patch 已经回移植到了 8.6.5、8.4.5、8.2.8、7.4.10、7.2.15、6.2.23 等版本。
写在最后
CVE-2026-66373 再次提醒我们：内存安全类漏洞的修复往往像"打地鼠"，堵了一个出口，另一个隐蔽路径可能还在漏水。Redis 作为无数互联网服务的核心缓存和消息中间件，它的安全性直接关系到整个架构的稳定性。这次漏洞虽然需要认证才能触发，但一旦攻击者已经拿到了 Redis 账号（比如通过内网横向移动或者凭证泄露），RESTORE 就成了从"数据读取"跃升到"服务器控制"的跳板。
建议各位运维同学这个周末就抽时间盘点一下自己手里的 Redis 实例版本。如果还在 8.8.0 以下，升级计划该排上日程了。毕竟 PoC 已经公开，留给防御方的窗口期从来不会太长