上周，当安全研究员悄悄把名为 wp2shell 的远程代码执行漏洞通知 WordPress 厂商时，节奏更像一次常规的披露流程。研究员没有公开细节，只是给出漏洞组合的抽象描述：REST API 批量路由混淆，再加上一个 SQL 输入问题，两条链路一旦串联，就能在目标主机上执行任意代码。而几乎在同一时刻，另一条赛道上的黑客已经在用 AI 对着开源仓库的代码差异比对，自己“补全”出完整利用链。

这种速度差带来的后果很快就体现在蜜罐数据上。安全公司 watchTowr 发现，漏洞公告发布后的几个小时内，就有攻击者拿到实际的远程执行能力。他们先通过公开的弱点窃取哈希凭证，紧接着就投下远控脚本。同一时期，其他安全团队部署的蜜罐系统在极短时间里承受了数万次攻击尝试，全自动的扫描脚本正在地毯式寻找每一个还开着漏洞的站点。

打开网易新闻 查看精彩图片

厂商这边的反应并不慢。WordPress 官方迅速释出修复版本，并通过后台的自动更新机制推送给允许“维护和安全版本”的站点。受影响范围被锁定在 6.9.0 至 6.9.4，以及 7.0.0 至 7.0.1，而更老的 6.8.5 及以下版本反而不受此次漏洞波及。同时，6.9.5 和 6.8.6 已经背移植补丁，7.1 Beta 2 之后的版本也已修复。这意味着，只要网站没有刻意关掉自动更新，理论上应该能在攻击规模爆发前收到保护。

但问题就出在“刻意关闭”上。大量生产环境出于稳定性考虑，会主动禁用 WordPress 核心的自动更新，此时唯一的安全线就是管理员手动升级。而攻击侧恰恰利用了开源项目的透明优势——每次版本更新都会留下代码变更记录，AI 只要把前后两个版本的源码输入，就能在极短时间内定位修补的位置，进而反向推导出漏洞触发条件。这个过程在过去可能靠人肉分析需要数天，现在几小时内就走完了。

打开网易新闻 查看精彩图片

随后发生的就是典型的批量杀伤链：扫描全网存活站点、探测可利用版本、投递 payload、植入恶意文件。根据蜜罐捕获的行为，黑客会在攻陷的站点里创建新的管理员账号，或者静默安装陌生插件，以此形成持久化控制。这也解释了为什么安全厂商给出的紧急建议里，除了立即升级到最新维护版本，还多了一条——立即检查是否存在不明管理员账户、并非自己安装的插件，以及服务器上任何异常文件。

对于那些暂时无法升级的站点，Cloudflare 这样的中间层提供了一道缓解方案：已部署云端规则对针对该漏洞的利用流量进行拦截。但安全研究员再三强调，这只是把攻击挡在外面，并没有封堵漏洞本身。只要应用的底层代码还存在缺陷，任何绕过 WAF 的手法都可能重新撕开口子。彻底的解决办法仍然是执行更新。

wp2shell 这一幕很难用传统的“攻防不对等”来概括。它更像是把原本由安全研究者、厂商和攻击者组成的时间差，被 AI 压扁成一个几乎同步的赛道。补丁推送的“正在路上”，和攻击脚本的“已经开始”，中间只隔了几个小时。而这几小时里，没有自动更新又没人值守的站点，就是最先被扫中的那一片。