文章总结： RedisStream相关漏洞CVE-2026-25243补丁绕过，攻击者利用RDB加载时nack对象共享缺陷，触发useafterfree和doublefree，通过jemalloc实现任意地址读写，最终劫持函数指针获得远程代码执行。影响Redis6.2.22、7.4.9、8.6.4等版本，8.8.0修复。防御建议包括升级、限制危险命令、不暴露公网、强化认证。 综合评分： 100 文章分类： 漏洞分析,红队,应急响应,漏洞预警
Redis 再曝高危漏洞：CVE-2026-25243 补丁绕过，可从认证用户到远程代码执行
云梦DC 云梦DC
云梦安全
2026年7月28日 11:36 日本
在小说阅读器读本章
去阅读
近日，安全研究人员公开分析了一枚 Redis Stream 相关漏洞。
这个漏洞比较特殊：
它不是一个普通的新漏洞，而是CVE-2026-25243 的补丁绕过版本。
攻击者无需 Redis 管理权限，只需要拥有有效认证凭据，并且目标允许执行部分高危命令，就可能通过精心构造的数据触发：
堆双重释放（Double Free） → 任意地址读写 → 函数指针劫持 → Redis 远程代码执行（RCE）
漏洞影响多个 Redis 版本，包括：
Redis 6.2.22
Redis 7.4.9
Redis 8.6.4
目前 Redis 8.8.0 通过代码重构修复了这一攻击面。
一、从 Redis Stream 消费者组说起
很多 Redis 用户熟悉：
String
Hash
List
Set
但 Redis 也提供了一套消息流机制：
Redis Stream。
它类似一个轻量级消息队列。
例如：
producer
|
Redis Stream
|
consumer group
多个消费者可以共同处理消息。
为了保证消息可靠消费，Redis 引入了：
Pending Entries List（PEL）
也就是：
待确认消息列表。
当消费者读取消息后，如果没有执行 ACK：
这条消息会进入 PEL。
Redis 会记录：
哪个消费者领取了消息；
消息 ID；
投递次数；
状态信息。
问题，也正出现在这里。
二、漏洞核心：两个消费者共享了一块内存
正常情况下：
消费者 A：
PEL
|
+– streamNACK 对象 A
消费者 B：
PEL
|
+– streamNACK 对象 B
两个消费者应该拥有独立的 NACK 结构。
但是在 Redis 加载 RDB 数据时：
出现了一个逻辑错误。
当 Redis 从 RDB 文件恢复 Stream 消费者组数据时：
如果两个消费者引用同一条消息 ID：
Redis 没有创建新的 NACK 对象。
而是：
直接复用了之前创建的对象。
结果：
消费者 A
|
|
streamNACK C
|
|
消费者 B
两个消费者指向了同一块内存。
三、为什么共享对象会造成漏洞？
问题在于：
Redis 后续会认为：
这个对象属于每个消费者独立管理。
于是：
攻击者执行：
XGROUP DELCONSUMER
删除消费者 A。
Redis：
释放 NACK C。
此时：
消费者 B：
仍然保存：
streamNACK C
但这块内存已经被释放。
形成：
Use After Free（释放后使用）
随后：
攻击者再次删除消费者 B。
Redis：
再次释放 C。
于是：
出现：
Double Free（双重释放）
四、从内存错误到 RCE：攻击链如何形成？
很多人看到 Double Free 会问：
释放一次内存，为什么能执行命令？
关键在于：
Redis 使用的内存分配器：
jemalloc。
jemalloc 存在：
tcache 缓存机制。
简单理解：
释放的内存块不会立即销毁。
而是进入缓存：
free()
↓
tcache
↓
下一次 malloc()
如果攻击者能够控制：
释放后的内存再次被分配给自己。
就可以制造：
内存复用。
整个利用过程大致分为几个阶段。
阶段 1：利用 UAF 获取任意读能力
攻击者首先构造恶意 Stream 数据。
通过：
RESTORE
加载特殊 RDB 数据。
让两个消费者共享 NACK。
然后：
XGROUP DELCONSUMER
触发释放。
之后攻击者通过堆喷：
覆盖已经释放的内存区域。
构造假的 Redis 对象。
最终实现：
读取 Redis 进程任意地址。
阶段 2：Double Free 建立任意读写
双重释放之后：
同一个内存块可能被 jemalloc 返回两次。
攻击者利用这一点：
构造：
fake dictEntry
fake robj
fake sds
让 Redis 的数据结构指向攻击者控制的位置。
最终获得：
任意地址读写能力。
阶段 3：泄露关键地址
现代 Linux 环境存在：
ASLR。
攻击者不能直接知道：
Redis：
PIE 地址
libc 地址
内存结构地址
因此需要先泄露地址。
利用任意读能力：
攻击者可以获取：
Redis binary base
libc base
内部数据结构地址
为后续代码执行准备条件。
五、最终 RCE：劫持 Redis 函数指针
Redis 内部大量使用函数指针。
其中：
dictType：
负责哈希表操作。
包含：
hashFunction
keyCompare
等函数。
攻击者通过任意写：
修改：
dictType.hashFunction
指向：
system()
之后：
Redis 执行哈希计算时：
调用：
hashFunction(command)
实际变成：
system(command)
最终：
攻击者获得 Redis 用户权限下的代码执行。
六、为什么说这是 CVE-2026-25243 的补丁绕过？
原漏洞修复重点：
解决某些场景下：
NACK 对象异常共享。
但是研究人员发现：
RDB 加载路径仍存在遗漏。
也就是说：
旧补丁修复的是：
某一个入口
而攻击者找到的是：
另一个代码路径
这也是很多补丁绕过漏洞的共同特点：
修复了攻击方法，但没有消除产生问题的根因。
七、漏洞利用条件
虽然漏洞危险，但并不是远程匿名攻击。
攻击者需要满足：
- 拥有 Redis 认证凭据
例如：
requirepass
泄露。
- 目标开放危险命令
包括：
RESTORE
XGROUP
EVAL
等。
- 可以访问 Redis 服务
例如：
公网暴露：
6379/tcp
或者内部网络可达。
八、哪些版本受影响？
受影响：
| Redis版本 | 状态 | | — | — | | Redis 6.2.22 | 受影响 | | Redis 7.4.9 | 受影响 | | Redis 8.6.4 | 受影响 |
修复：
Redis 8.8.0+
该版本通过 PR#15081重构相关代码路径，从根本上避免 NACK 对象共享。
九、防御建议
- 优先升级 Redis
建议升级：
Redis >= 8.8.0
这是最有效的方式。
- 限制危险命令
如果业务不需要：
建议限制：
RESTORE
EVAL
XGROUP
等命令。
可以通过 ACL：
限制普通账号权限。
- 不要暴露 Redis 到公网
Redis 服务：
不要直接开放：
0.0.0.0:6379
建议：
内网访问；
防火墙限制；
安全组控制来源。
- 强化认证
避免：
弱密码：
redis123
admin123
同时开启：
ACL 用户隔离。
十、总结
CVE-2026-25243 补丁绕过再次证明：
内存安全漏洞往往不是简单修一个判断条件就能结束。
Redis 这次的问题：
从一个看似普通的数据结构共享错误开始：
NACK对象共享
↓
Use After Free
↓
Double Free
↓
任意读写
↓
函数指针劫持
↓
RCE
整个攻击链展示了现代堆利用的复杂性。
对于企业来说，Redis 最大的风险并不只是漏洞本身。
更重要的是：
不要让一个存储服务同时暴露公网、开放危险命令、使用弱认证。
因为一旦认证凭据泄露，一个看似普通的 Redis 实例，可能直接成为攻击者进入服务器的入口。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：云梦安全 云梦DC 云梦DC《Redis 再曝高危漏洞：CVE-2026-25243 补丁绕过，可从认证用户到远程代码执行》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论