7月23日，研究人员”Bera Buddies”在社交媒体上公布了一项震惊安全圈的发现：Moonshot AI（中文名：月之暗面）新发布的Kimi K3模型，仅凭一条简单的指令——”找出内存破坏类漏洞，如缓冲区溢出和释放后使用漏洞”——在27分钟内完成了一套完整的漏洞发现工作流程。

整个过程包括：克隆Redis源代码、执行模糊测试、使用GDB调试崩溃分析，最终为Redis 6.2.22、7.4.9、8.6.4和8.8.0四个版本生成了非破坏性漏洞利用代码。成果已发布至GitHub：github.com/berabuddies/redis-poc

这不是第一次有人用AI找漏洞，但27分钟从指令到可用的RCE漏洞利用代码，这个速度和自动化程度，直接把”AI辅助漏洞挖掘”从概念变成了现实。

二、技术细节：两个漏洞两条路

2.1 Stream NACK双重释放漏洞（影响6.2.22/7.4.9/8.6.4）

第一个漏洞类型为双重释放（double-free），存在于Redis Stream消费者组的共享NACK路径中，与CVE-2026-25589的不完全修复相关。

双重释放的原理很直接：程序对同一块堆内存执行了两次free()操作。当第二次free时，堆管理器可能将这块内存重新分配给其他数据结构，攻击者就能通过精心构造的内存布局来覆写关键指针，最终实现代码执行。

受影响版本：

• Redis 6.2.22
• Redis 7.4.9
• Redis 8.6.4

这三个版本都存在这个shared-NACK路径的double-free问题，而该问题直到Redis 8.8.0才通过PR #15081完全修复。

2.2 TDigest堆溢出漏洞（影响8.8.0）

在Redis 8.8.0中，NACK问题已被修复，但Kimi K3又发现了另一个漏洞——RedisBloom模块中TDigest数据结构的堆溢出问题。

TDigest是一种概率数据结构，常用于近似百分位数计算，在高性能应用场景中被广泛使用。这个堆溢出漏洞允许攻击者在特定条件下覆写相邻内存区域，从而实现远程代码执行。

值得注意的是，8.8.0版本的漏洞利用具有布局敏感性——它依赖于喷洒TDigest结构来构建确定性的jemalloc内存布局，因此建议在全新的实例上测试，且测试过程中避免其他并发命令干扰。

2.3 受影响版本一览

两个漏洞利用路径都需要EVAL、RESTORE和XGROUP这三个命令——这些命令在很多内部部署场景中往往处于开放状态。

三、漏洞利用代码解析

GitHub仓库中提供了针对不同版本的漏洞利用脚本：

• A_exploit_stock.py：针对Redis 6.2.22（默认开启DEBUG模式）
• P74_exploit.py（+P74_g2.py）：针对Redis 7.4.9（无需DEBUG标志）
• P86_exploit.py：针对Redis 8.6.4（无需DEBUG标志）
• P88W_exploit.py（+P88W_lib.py、P88W_corrupt.py）：针对Redis 8.8.0（通过TDigest堆溢出）

使用方式也很简单：

# 7.4.9版本示例
docker run -d -p 6379:6379 redis:7.4 redis-server --requirepass exploitme
python3 P74_exploit.py 127.0.0.1 6379 exploitme "id > /data/pwned74"


所有漏洞利用代码均为非破坏性，默认为目标系统写入证明文件（/data/pwned*），而非直接接管系统。

四、攻击链分析：从数据存储到主机shell

Redis通常位于应用层之后，有密码保护，但命令面是完整的。一旦攻击者通过以下方式获取凭据：

• 密钥泄露（Secret Leak）
• 服务端请求伪造（SSRF）
• 网络ACL配置错误

就可以从”数据存储访问”直接升级为”主机层面shell”，而且这个过程不会以明显异常的方式崩溃服务。

这就是红队思维中的”从入口到目标”的经典路径——Redis不只是个数据库，它是一个隐藏的攻击面。

五、防御建议

针对这两个漏洞，建议立即采取以下措施：

紧急措施

• 将Redis升级到官方发布的安全修复版本
• 使用rename-command禁用EVAL、RESTORE等危险命令
• 通过Redis ACLs拒绝应用用户使用管理命令

网络隔离

• 将Redis绑定到私有接口
• 绝对不要将6379端口暴露到互联网

认证与密钥管理

• 使用强密码，杜绝默认凭据
• 定期轮换密钥，任何疑似泄露后立即更换

模块审计

• 禁用或卸载未使用的RedisBloom/TDigest模块
• 追踪官方Redis和RedisBloom的安全公告

监控告警

• 监控异常的XGROUP/RESTORE/EVAL使用行为
• 关注数据目录下出现异常密钥

六、AI漏洞挖掘的里程碑

Kimi K3的这次表演，不仅仅是”又一个AI找漏洞”的案例。27分钟、32个智能体、自主完成从代码克隆到漏洞利用生成的完整链路——这意味着什么？

意味着漏洞发现的门槛正在急速下降。传统上，一个有经验的安全研究员手动审计Redis这样的大型项目，需要数天甚至数周。而AI把这个时间压缩到了半小时以内。

当然，这是一把双刃剑：

• 防御方：可以用AI快速发现自身系统的漏洞，加速修复
• 攻击方：同样可以用AI加速漏洞利用开发

安全社区已经呼吁负责任的披露——在厂商收到通知并有足够时间修复之前，不应大范围传播漏洞利用代码。

版权声明：本文由华盟网原创发布，保留所有权利。