一、先说说 Kimi K3 最近为什么这么火

如果你最近刷科技圈，很难绕开 Kimi K3 这个名字。这是月之暗面刚发布的开源大模型，2.8万亿参数，支持原生视觉和100万token上下文。

更让开发者圈沸腾的是一件小事：有开发者把同一份安全漏洞报告丢给三家AI，OpenAI的Codex拒修，Anthropic的模型拒修，理由都是"安全护栏"。只有Kimi K3，二话不说，15个漏洞全部修完。前白宫AI顾问David Sacks专门发帖点评，拿了上万赞。

一句话总结它的优点：开源、能干活、不矫情。

二、27分钟，发生了什么？漏洞具体信息是什么？

7月下旬，安全研究员 Chaofan Shou 公开了一项实验：让 Kimi K3 驱动32个AI智能体，对 Redis 的官方版本进行自动化漏洞挖掘。Redis是全球部署最广泛的内存数据库之一。你用的几乎所有互联网服务——淘宝的购物车、微信的会话、各种App的缓存——背后大概率都有它。

结果：27分钟，找到漏洞，并写出了可用的攻击代码（PoC），直接发布在GitHub上，这次曝光的漏洞有两类：

• Streams 双重释放漏洞：影响 Redis 6.2.22、7.4.9、8.6.4。攻击者可以让同一块内存被释放两次，进而执行任意命令。它属于一个"没修干净的旧补丁"家族（CVE-2026-25589）。

• RedisBloom TDigest 堆溢出：影响最新的 8.8.0。就算你把旧漏洞都修了，这个内置模块里的新漏洞依然能让你"裸奔"。

两条链的共同点：只需要一个已认证的连接（比如密码泄露、SSRF、ACL配置失误），就能从"访问数据库"直接升级到"控制整台服务器"，拿到Shell。

Redis官方反应很快，7月23日一口气发布了7个安全更新。但截至目前，新旧版本的CVE编号和评分还没完全录入，也就是说——补丁有了，很多公司甚至还没意识到自己该打。

三、谁最该紧张？普通人要慌吗？

最该紧张的是运维、DBA和自建Redis的公司。

Redis通常藏在应用后面，大家觉得"有密码就安全"。但这次的研究恰恰证明：一旦攻击者摸到凭证，之前是"能看你的数据"，现在是"能拿走整台机器"。尤其是那些用默认配置跑的测试环境、CI环境、轻负载生产Pod——成功率最高。

普通用户基本没有直接影响。

你不用去改手机设置，也不用卸载什么软件。这事发生在服务器端，和你日常刷视频、点外卖没有关系。唯一的间接影响是：如果某个你常用的平台运维不给力，理论上存在数据泄露风险——但截至目前，尚未发现在野利用，各大云厂商和主流平台大概率已经在连夜升级了。

真正睡不着觉的，是今晚要对版本号的那批人。

四、修复建议（给运维的速查清单）

如果你在维护Redis，按优先级做这几件事：

1. 立刻升级。各分支修复版本：6.2.23 / 7.2.15 / 7.4.10 / 8.2.8 / 8.4.5 / 8.6.5 / 8.8.1。注意：5月份打过的补丁不管用，那次的修复不完整。

2. 升级前先做应急止血：用ACL把 RESTORE 命令从不需要它的账号上收掉。两条已公开的攻击路径都依赖它，禁掉等于直接剪断引信。EVAL 和 XGROUP 同理，按需收紧。

3. 检查网络暴露面：Redis不该出现在公网。确认bind配置、安全组、防火墙，阻断一切不可信来源的访问。

4. 排查凭证泄露：密码有没有进过Git仓库、日志、聊天记录？有的话直接轮换。

一句话：先收RESTORE权限，再连夜升级，顺序别反。

五、最后说两句冷静的

热闹归热闹，有几个细节值得说清楚：

第一，这不是严格意义上的"AI从零发现未知漏洞"。其中一个问题Redis官方其实已有察觉，补丁早就在准备了；而且27分钟、32个智能体这些数据，目前只有研究者本人的说法，完整日志没公开。

第二，就在同一周，英美两家AI安全机构的联合评测显示，Kimi K3在系统性漏洞利用能力上其实落后于美国前沿模型不少。所以别急着喊"AI黑客时代降临"，也别因为它分数不高就觉得无所谓。

真正值得记住的是这个趋势：漏洞挖掘的速度，正在从"按周算"变成"按分钟算"。 攻击方用AI加速，防守方唯一的选择就是也用AI加速——自动化补丁、自动化验证、灰度发布，这些以前"锦上添花"的东西，很快会变成保命的基本功。

以前是人和人赛跑，现在是机器和机器赛跑，而你的服务器，是跑道。