摘要： Redis连曝多枚RCE漏洞，最新TLS待处理链表漏洞（QVD-2026-58458）细节与PoC已公开，官方紧急发布修复版本。
做后端的对Redis都熟：缓存、会话、消息队列、排行榜，哪儿都有它。但也正因为哪儿都有它，Redis出一个洞，全行业就得跟着抖三抖。
过去这一个多月，Redis接连曝出多枚远程代码执行漏洞。8月26日，奇安信威胁情报中心监测到官方紧急修复了Redis TLS待处理链表远程代码执行漏洞（QVD-2026-58458）——技术细节和PoC已经公开，安全研究员完成了复现。而就在一周前，另一枚高危RCE（QVD-2026-55651）刚刚公开。再往前翻，7月底还有一枚针对此前补丁的”绕过型”漏洞。
一个月三枚RCE，这不是偶然，是攻击者和研究者都盯上了这块肥肉。
三枚漏洞里，最有代表性的是7月底披露的那枚——它是CVE-2026-25243的补丁绕过。
事情是这样的：官方之前修了流消费者组（stream consumer-group）里共享NACK对象的引用计数问题，但补丁没修干净。攻击者用XGROUP、EVAL、RESTORE这几条命令构造特定的流操作序列，照样能触发共享NACK对象的双重释放（Double Free），最终把这个内存破坏原语变成服务器上的任意代码执行。
补丁绕过类漏洞为什么危险？因为它专门猎杀”以为自己安全了”的人。很多团队看到CVE-2026-25243的补丁出来，打完就收工了，资产台账上标个”已修复”。结果绕过手法一公开，这批”已修复”的机器一夜之间全部回到裸奔状态。
安全圈有句老话：补丁不是终点，是攻击者的起跑枪。绕过分析是漏洞研究的常规动作，你打完补丁的那一刻，黑客的diff分析才刚刚开始。
以前述补丁绕过漏洞为例，受影响范围是Redis 6.2.22及以下、7.4.9及以下、8.6.4及以下——基本把生产环境里能见到的版本一网打尽，官方修复版本是8.8.0及以上。而8月26日修复的TLS待处理链表漏洞（QVD-2026-58458）细节和PoC也已公开，意味着利用门槛已经低到”脚本小子照着抄”的水平。
需要说明一点：这几枚漏洞的利用前提是需要经过身份验证。别看到”需要认证”就松一口气——现实里的Redis是什么状态，干过安全的都清楚：弱密码、空密码、默认端口直接挂内网甚至公网，批量扫描器24小时不间断地摸。所谓的”认证门槛”，在很多环境里约等于没有门槛。
一旦被打穿，后果不只是缓存数据泄露。Redis服务器往往处在内网枢纽位置，攻击者拿下它，可以以服务器进程上下文执行任意代码，接着就是标准的内网渗透剧本：翻配置找凭据、扫内网摸资产、横向移动到数据库和业务机。Redis沦为一个洞，整个内网跟着遭殃。
1. 版本自查与升级。 先跑一遍资产扫描，把全公司所有Redis实例的版本号拉出来——注意是”所有”，包括测试环境、历史遗留环境、业务方自己偷偷搭的实例。在受影响范围内的，评估后升级到官方最新修复版本（参考Redis官方发布页）。
2. 网络访问收口。 Redis不该有任何公网暴露。内网也要做白名单，只允许必要的业务IP连接。顺手查一遍requirepass/ACL配置，弱密码、空密码当场整改。
3. 日志审计。 排查异常的命令执行序列，重点关注XGROUP、EVAL、RESTORE等高危命令的非常规调用，以及来源陌生的连接记录。EVAL能执行Lua脚本，历来是Redis攻击的重灾区，非必要可在ACL层面限制。
4. 容器化环境额外注意。 很多团队用容器跑Redis，记得镜像仓库里的基础镜像版本也要更新，别出现”宿主机升了、镜像还是旧的”这种半截子工程。
5. 建立补丁跟踪机制。 连续三枚RCE说明Redis正处于漏洞高发期。把Redis官方安全公告和奇安信、CNVD这类情报源纳入日常监测，别再靠朋友圈刷到才知道出事了。
这一轮Redis漏洞潮给所有安全团队提了个醒：基础设施组件的安全水位，直接决定整个防御体系的下限。缓存、队列这类”配角”组件平时没人关注，可一旦出事就是全网震动。
补丁绕过、PoC公开、版本全覆盖——三个要素凑齐，接下来就是比速度：是你升级快，还是扫描器找上你快。
今晚就把资产清单拉出来对一遍版本号。Redis这种躺在架构最深处的东西，平时不出声，一出声就是大事。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。