自主 AI 工具发现潜伏两年的 Redis 远程代码执行漏洞 (CVE-2026-23479)

导语：在网络安全领域，传统扫描工具依赖已知特征码，面对复杂的逻辑漏洞往往束手无策。然而，2025年12月伦敦的ZeroDay.Cloud黑客竞赛上，一款名为Xint Code（辛特代码）的自主AI安全工具，挖出了Redis数据库中一个潜伏两年之久的远程代码执行漏洞。攻击者只需一个认证会话，就能以Redis服务权限在主机上执行任意系统命令。

一、事件背景

1.1 漏洞概况

该漏洞编号为CVE-2026-23479，美国国家漏洞数据库（NVD）给出的CVSS 3.1评分为8.8（高危），Redis官方则给出CVSS 4.0评分7.7。

漏洞类型为Use-After-Free（释放后重用，UAF），位于Redis的阻塞客户端代码路径中，具体函数为unblockClientOnKey()。当一个键事件唤醒被阻塞的命令时，该函数通过processCommandAndResetClient()分发队列中的命令——问题在于，该函数可能将客户端作为副作用释放，但调用者完全忽略返回值，继续使用已被释放的客户端指针，形成典型的释放后重用漏洞。

1.2 时间线与引入过程

该漏洞的"诞生"过程堪称讽刺：两个独立的代码提交单独看都无害，组合在一起却制造了一个高危漏洞。

2023年1月：PR #11012 引入了一个未检查的函数调用，为后续问题埋下伏笔。
2023年3月：PR #11568 在已释放的客户端之后添加了更多访问操作。
2023年：两个PR的组合随着Redis 7.2.0版本公开发布，漏洞正式进入稳定分支。
此后超过两年、多轮安全审查，该漏洞始终未被察觉。
2025年12月：Xint Code（辛特代码）自主AI工具在ZeroDay.Cloud黑客竞赛中将其挖出。
2026年5月5日：Redis官方发布全面补丁，覆盖全部五个维护版本分支。

二、漏洞利用链详解

2.1 利用条件

完整的攻击链需要认证会话具备以下ACL权限：

@admin（管理权限）
@scripting（Lua脚本执行）
@stream（流命令，如XREAD/XADD）
@read/@write（基本读写）

在默认部署中，Redis的默认用户已拥有上述所有权限，且大多数部署中这些权限被归入单一共享应用角色，使得攻击门槛进一步降低。

2.2 三阶段攻击链

第一阶段：堆地址泄漏

攻击者仅需一行Lua脚本：

EVAL "return tostring(redis.call)"0

该脚本泄露Redis堆内存地址，绘制服务器内存布局图，为后续攻击提供必要的位置信息。

第二阶段：堆内存整形

攻击者通过CONFIG SET maxmemory-clients调整客户端内存限制，对堆进行"整形"，将一个臃肿的客户端停放在流（stream）上。随后降低内存限制并唤醒被阻塞的客户端——此时Redis在调用过程中释放了被阻塞的客户端，而攻击者通过管道化的SET命令立即用伪造的客户端结构体重占该已释放内存槽。

第三阶段：函数指针劫持

Redis在updateClientMemoryUsage()中的常规内存统计操作，会利用攻击者控制的字段执行一次越界递减，目标直指全局偏移表（GOT）。由于官方Redis Docker镜像采用部分RELRO（只读重定位），GOT在运行时仍可写，这使得攻击者得以将strcasecmp()函数重定向到system()。

下一条Redis解析的命令，将直接作为Shell命令执行。

ASLR和PIE在此无效，因为写入目标是基于构建时固定的全局偏移量，不受地址空间随机化影响。

三、影响范围与修复方案

3.1 受影响版本

分支	受影响版本	修复版本
Redis 7.2.x	7.2.0 – 7.2.13	7.2.14
Redis 7.4.x	7.4.0 – 7.4.8	7.4.9
Redis 8.2.x	8.2.0 – 8.2.5	8.2.6
Redis 8.4.x	8.4.0 – 8.4.2	8.4.3
Redis 8.6.x	8.6.0 – 8.6.2	8.6.3

所有版本均发布于2026年5月5日，同批还披露了另外四个RCE级别的Redis漏洞（CVE-2026-25243、CVE-2026-25588、CVE-2026-25589、CVE-2026-23631）。

3.2 立即行动

升级到安全版本（优先级最高）：同系列内的次版本升级应为无缝替换，请立即检查并升级Redis实例。

临时缓解措施（如无法立即升级）：

将Redis从公网撤下，置于TLS后方。
收紧ACL，确保没有单一角色同时持有@admin、CONFIG和@scripting权限。
若未使用Lua脚本功能，禁用@scripting，这将阻断第一阶段地址泄漏。
优先处理：公网暴露实例、共享应用凭据、同时拥有CONFIG/脚本/流访问权限的角色。

同时轮换所有广泛共享的Redis凭据。

四、这不是典型漏洞——AI看见了什么

传统的SAST（静态应用安全测试）工具和人工代码审查为何两年都没发现这个漏洞？

Qualysec（夸利安全）的分析指出：传统扫描工具依赖已知漏洞模式或基础代码语法错误，擅长发现简单的空指针解引用或缓冲区溢出。但Use-After-Free的触发条件跨越两个独立的代码提交，需要理解数据在复杂代码库中的流动方式才能发现。

Xint Code（辛特代码）并非简单地扫描代码，它通过自主分析，理解了Redis内部各模块之间的数据传递逻辑，发现了"两个单独提交都是安全的，但组合在一起产生了逻辑漏洞"这一关键事实。这是AI在网络安全领域超越传统工具的重要分水岭。

五、行业启示

5.1 逻辑漏洞正在成为AI的猎物

长期以来，逻辑漏洞（Logic Vulnerability）被认为比内存损坏类漏洞更难自动化发现，需要深入理解代码业务逻辑。然而，当AI能够自主分析复杂代码库中的数据流时，这一假设正在被打破。

5.2 云部署加剧风险

云安全公司Wiz的分析指出，Redis在绝大多数云环境中都有部署，且其中大多数实例以无密码方式运行。结合默认用户拥有全部所需权限，这意味着在大多数云部署中，漏洞利用的前置条件（认证）几乎天然满足。

5.3 代码审查存在盲区

两个代码提交在各自独立审查时均被判定为安全，但组合后产生了可利用的漏洞。这揭示了传统代码审查在面对组合逻辑漏洞时的结构性缺陷：评审者通常一次审查一个PR，缺乏跨PR的组合攻击面分析能力。

六、安全建议

立即升级：将所有Redis实例升级至7.2.14、7.4.9、8.2.6、8.4.3或8.6.3。
网络隔离：不要将Redis直接暴露在公网，使用TLS并配合防火墙。
最小权限：拆分默认用户的权限，不要让单一角色同时持有管理、脚本和流命令权限。
禁用未使用的功能：如无Lua脚本需求，禁用@scripting权限。
凭据轮换：轮换所有Redis凭据，特别是共享应用账号。
引入AI安全扫描：将AI辅助的漏洞扫描工作流纳入CI/CD和安全审查流程。

七、参考资料

The Hacker News：《Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)》 https://thehackernews.com/2026/06/autonomous-ai-tool-finds-2-year-old-rce.html
Qualysec：《Autonomous AI Tool Uncovers Redis RCE Flaw (CVE-2026-23479)》 https://qualysec.com/cybersecurity-news/autonomous-ai-tool-finds-2-year-old-rce/
ZeroDay.Cloud 技术报告：《Redis CVE-2026-23479 Deep Dive》 https://www.zeroday.cloud/blog/redis-cve-2026-23479-deep-dive
Redis 官方安全公告 https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/
NVD 漏洞详情 https://nvd.nist.gov/vuln/detail/CVE-2026-23479

👇 点击阅读原文，访问我的网站