Redis 严重漏洞可导致远程代码执行攻击

2026-05-07 22:35:27 1 76

Redis 中的五个危险漏洞使 Redis Cloud、Redis Software 和所有开源社区版本面临远程代码执行的风险,从而使经过身份验证的攻击者能够直接入侵受影响的系统。


Redis 中的五个危险漏洞使 Redis Cloud、Redis Software 和所有开源社区版本面临远程代码执行的风险,从而使经过身份验证的攻击者能够直接入侵受影响的系统。

所有这些漏洞都需要经过身份验证才能利用,但成功利用漏洞可能导致任意代码执行 、系统完全被攻破、数据泄露或服务中断。

该安全公告由 Riaz Lakhani 于 2026 年 5 月 5 日发布,是 Redis 持续安全举措的一部分。公告中指出,四个漏洞被评为高危漏洞,CVSS 评分为 7.7;另有一个漏洞被评为中危漏洞,CVSS 评分为 6.1。

Redis 远程代码执行漏洞


CVE-2026-23479 是解除阻塞客户端流程中的一个释放后使用漏洞。

当被阻塞的客户端在重新执行阻塞的命令时被驱逐,代码无法处理 processCommandAndResetClient 返回的错误,从而允许经过身份验证的用户触发释放后使用的情况 ,并有可能执行远程代码。

CVE-2026-25243 影响 Redis RESTORE 命令。已认证用户可以通过发送特制的序列化有效载荷触发无效内存访问,从而可能导致在 Redis 服务器上下文中执行任意代码。

独立研究员 Emil Lerner 发现了双重释放变体,而 Joseph Surin 则发现了 VectorSets 中的整数溢出和越界读取问题。

CVE-2026-25588 和 CVE-2026-25589 分别是使用 RedisTimeSeries 和 RedisBloom 模块时 RESTORE 命令中密切相关的缺陷。

两者都允许经过身份验证的攻击者通过精心构造的序列化有效载荷触发无效的内存访问,从而导致相同的远程代码执行影响。

Joseph Surin、John Stephenson 和 Annie Nie 发现了 TimeSeries 的缺陷;Daniel Firer 和 Joseph Surin 发现了 RedisBloom 的多个问题,包括越界读取和写入、整数溢出和堆缓冲区溢出。

CVE-2026-23631 是一个中等严重程度的 Lua 释放后使用漏洞。已认证用户可以利用主从同步机制触发此漏洞。

该漏洞专门影响配置了禁用副本只读功能的 Redis 副本,并且存在于所有启用 Lua 脚本的 Redis 版本中。研究员 Yoni Sherez (@yoyosh__) 发现了该漏洞。

所有 Redis Cloud 部署均已完成补丁更新,无需客户采取任何操作。对于自行管理的部署,所有 Redis OSS/CE 版本均受影响。已发布的修复版本如下:

Redis OSS/CE:6.2.22、7.2.14、7.4.9、8.2.6、8.4.3 和 8.6.3。Redis 软件版本 8.0.6 及更高版本均受影响,修复程序可在版本 8.0.10-64、7.22.2-79、7.8.6-253、7.4.6-279 和 7.2.4-153 中找到。

模块特定的修复包括 RedisTimeSeries v1.12.14、v1.10.24、v1.8.23 和 RedisBloom v2.8.20、v2.6.28、v2.4.23。

如何保护您的 Redis 实例


Redis 确认,截至发稿时,没有证据表明存在实际的恶意利用行为。

但是,运行自托管实例的组织应立即采取行动。主要缓解措施包括:

升级到最新的修复版本是首要的修复步骤。您可以从 redis.io/downloads 下载。

除了打补丁之外,管理员还应该使用防火墙和网络策略来限制网络访问,只允许受信任的来源访问。

必须在所有实例中强制执行强身份验证,并且在 CE 和 OSS 部署中应保持启用 Redis 保护模式。

用户权限应遵循最小权限原则,限制对潜在危险命令的访问。

潜在攻击的迹象包括未经授权的访问尝试、带有 Lua 引擎堆栈跟踪的无法解释的服务器崩溃、redis-server 用户执行异常命令以及 Redis 配置或持久文件的意外更改。

Wiz 与 Redis 合作,通过其 ZeroDay.Cloud 平台发现了多个漏洞。

这反映了协作式漏洞赏金和漏洞研究计划在主动保护广泛部署的开源基础设施方面发挥着越来越重要的作用。

关于作者

weak_hong43篇文章55篇回复

评论1次

要评论?请先  登录  或  注册
  • 1楼
    昨天 22:36

    这波漏洞说实话有点尴尬——影响面是挺大的,但利用前提卡死了是"已认证"。说白了要么目标Redis压根没设密码(内网渗透场景常见),要么你有办法先拿到认证凭证。

    实操角度有几个思路值得注意:

    1. 弱口令和空口令仍是主入口。这批漏洞不会让空口令变有洞,但内网里Redis 6379直接裸奔的一抓一大把。很多老应用配置Redis连密码都懒得加,或者用的就是requirepass foobared这种。

    2. CVE-2026-23631这个Lua UAF比较特殊,需要能触发主从同步路径,而且要求副本关闭了只读。如果目标配了主从复制+弱ACL,这个点可以试试——比直接构造RESTORE payload干净一些。

    3. RedisTimeSeries和RedisBloom模块的洞容易被忽略。实战中很多用这些模块的靶场和内部xi统压根没跟进模块更新,管理员只会升主程序不升模块。

    4. 防御方的盲区:很多甲方只会升官方redis版本,模块不更新,这反而是个突破口。

    利用链一般是:拿到认证 → 选对应CVE → 触发RCE。没认证的情况下就老老实实先打弱口令或者找配置错误,漏洞利用是后半段的事。

    如果目标是内网,直接nmap -p 6379 --script redis-info先扫一遍,能连上的大概率没密码。