用 AI 帮写 RCE 漏洞利用代码，WeWorm 这种零点击蠕虫在 9 天内就跑通了

用 AI 写漏洞利用代码（Exploit）的速度快得离谱，Calif Research 团队在 2 天内通过 AI 找到了 Bug 并写出了远程代码执行（RCE）代码，之后又花了一周时间把这个漏洞封装成能通过微信通话传播的 WeWorm 蠕虫。这意味着 iOS 和 Android 用户即便不接电话、不操作手机，只要收到通话请求就可能被感染。

零点击漏洞的实际威胁到底有多大

所谓的“零点击”（Zero-click）是最让安全工程师头疼的，因为用户完全没机会通过“不点击可疑链接”来防御。WeWorm 的传播链路是通过微信通话触发，最恶心的地方在于：受害者不需要接听电话，甚至不需要碰手机，只要漏洞触发，攻击就完成了。就算你接了电话，由于攻击在后台静默执行，你听不到任何声音，但 RCE 已经跑完了。

这种漏洞的开发周期在 AI 介入前通常是以“月”计算的，需要资深安全研究员反复分析内存溢出、构造 Payload 并进行无数次崩溃测试。而这次 Calif Research 的案例证明，AI 现在能承担绝大部分的编码和分析工作，人类只需要提供“攻击目标”和“安全测试判断”这两个核心维度。

这种开发流程是怎么跑通的

虽然他们没有公开具体的 Prompt 链，但从 2 天写出 RCE 加上 1 周构建蠕虫的时间线来看，流程应该是这样的：

1. 漏洞挖掘阶段（2天）： AI 负责分析二进制文件或反汇编代码，快速定位潜在的内存损坏点，并尝试生成能触发 Crash 的输入向量。
2. 利用构建阶段（同步进行）： AI 根据内存地址和寄存器状态，快速尝试编写 Shellcode 或构造 ROP 链（Return-Oriented Programming）。
3. 蠕虫化封装（1周）： 这步需要处理传播逻辑，比如如何自动获取联系人列表、如何伪造通话请求、如何确保在不同版本系统上不崩溃，这部分代码量大且琐碎，AI 的效率提升最明显。

为什么我们不能盲目乐观

虽然 AI 缩短了开发周期，但要把一个 Bug 变成一个稳定的 Worm，依然需要极强的人类经验。如果你尝试用 LLM 直接写漏洞利用，大概率会遇到以下坑：

• 幻觉地址： AI 经常会胡编一个内存地址，导致程序直接 Segment Fault。
• 版本碎片化： 微信在 iOS 17.x 和 16.x 上的内存布局完全不同，AI 写出的代码在 A 机器能跑，在 B 机器直接崩。
• 缺乏实时反馈： AI 没法直接连接你的调试器（如 GDB 或 LLDB），它只能根据你喂给它的 Log 来猜为什么失败。

实际操作建议

如果你想尝试用 AI 来分析某个具体的协议或寻找 Bug，不要指望它直接给你一个 exploit.py，建议采取以下步骤：

• 喂入反汇编代码： 将 IDA Pro 或 Ghidra 导出的伪代码片段喂给模型，让它分析逻辑漏洞而非直接写代码。
• 迭代调试： 将崩溃时的寄存器快照贴给 AI，问它「为什么在这个偏移量处发生了溢出」，而不是问「怎么写利用代码」。
• 验证环境： 必须在与目标版本完全一致的镜像环境中测试。

这次 WeWorm 的出现给所有 App 开发者敲响了警钟：当 AI 能在 9 天内完成以前需要数月才能完成的攻击链路时，传统的补丁更新周期已经太慢了。