事件背景：AI 时代的漏洞挖掘新常态
近期，Redis 官方密集发布了七个安全版本更新，修复了存在于多个版本中的远程代码执行（RCE）漏洞。值得关注的是，此次漏洞的发现过程与以往不同——据研究人员披露，这些漏洞是由 AI Agent（如 Kimi K3）在短时间内自动化挖掘并构建出攻击链路的。
从我们的应急响应经验来看，攻击者利用 AI 技术进行漏洞挖掘和自动化攻击脚本生成的趋势正在加速。这意味着企业防御的“窗口期”被大幅压缩，传统的被动防御策略已难以应对这种高效率的自动化威胁。
攻击链深度解析
本次披露的漏洞主要涉及 Redis 的 RESTORE 命令，攻击者通过构造恶意的 RDB 文件，触发内存破坏漏洞，进而实现远程代码执行。主要存在两条攻击路径：
第一条是 Redis Streams 组件中的“共享所有权”漏洞（Shared-NACK）。漏洞成因在于 RDB 对象处理逻辑存在缺陷，使得多个消费者指向同一个挂起的记录条目。当这些消费者被移除时，会触发两次释放（Double-Free），导致内存破坏。攻击者利用这一机制实现任意内存访问，进而劫持哈希函数调用系统命令。
第二条路径位于 RedisBloom 模块的 TDigest RDB 加载器中。该漏洞属于典型的越界写入（Out-of-Bounds Write）。加载器在分配内存时未严格校验攻击者可控的容量字段，导致分配的缓冲区与实际加载的数据量不匹配，从而触发溢出。攻击者通过精心构造的载荷，能够实现内存地址泄露并最终执行系统级指令。
这一环节是很多企业容易忽视的：即 Redis 模块（如 RedisBloom）的安全性往往被视为“次要”，但实际上它们同样是通往系统内核的入口。
为什么说这是企业防御的警钟
虽然目前暂未发现大规模的在野利用，但类似攻击近年来明显增加。此次修复不仅涉及基础 Redis 版本，还覆盖了多个分支。特别是对于一些曾被认为“已修复”的旧版本（如 6.2.22 和 7.4.9），在本次更新中再次被证实存在隐患。
对于运维团队而言，简单的“更新到最新版”并不足够。很多企业在维护中倾向于只关注大版本更新，而忽略了微小补丁对特定功能（如 RESTORE、Streams）的防护强化。
Solar 应急响应建议
面对此类高危漏洞，建议企业采取以下行动：
首先，立即排查业务环境中的 Redis 版本。请根据您所使用的具体分支，尽快升级至对应的修复版本（如 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 或 8.8.1）。
其次，实施最小权限控制。RESTORE 命令是本次漏洞的“核心诱因”，如果您的业务逻辑中并不强制依赖该命令，建议在 Redis 配置中禁用或限制该命令的调用权限。
最后，加强网络边界防护。Redis 不应暴露在公网环境下，且应配合强认证机制。对于非信任的网络访问，务必在防火墙层进行阻断，避免未授权攻击者直接触达 Redis 服务端口。
AI 辅助挖掘漏洞的出现，标志着网络攻防进入了“快节奏”时代。企业应建立更敏捷的漏洞响应流程，确保在安全公告发布后的第一时间内完成资产梳理与加固。
如果您想了解勒索病毒的最新发展趋势，或在实际业务中遇到类似安全事件，欢迎关注“Solar应急响应团队”。
全国热线：400-613-6816 官网：www.solarsecurity.cn / www.sierting.com