25 美元 AI 挖出 50 万漏洞：当攻击跑到“小时级”，安全验证不能再等“季度末”

成本约 25 美元，耗时 10 个小时，AI 挖出了一条无需登录即可触发远程代码执行的 WordPress 漏洞链。

同等级 WordPress RCE 在漏洞交易市场上的最高报价可到 50 万美元。一边是 25 美元的模型使用成本，一边是 50 万美元的漏洞报价。这个落差，确实让人有点坐不住。

7 月 20 日，wp2shell 的发现过程公开。GPT-5.6 Sol Ultra 审查了最新版 WordPress 源码，最多同时运行 4 个 Agent。模型先找到预认证 SQL 注入，随后继续分析权限提升和远程代码执行路径。约 10 小时后，完整漏洞链形成。

到第 10 个小时，完整链条已经摆在研究者面前。

WordPress 随后发布 7.0.2 和 6.9.5 安全版本，并对受影响版本启用强制自动更新。受影响范围包括 6.9.0–6.9.4、7.0.0–7.0.1，默认安装环境、无需插件、匿名用户可触发。

WordPress 官方版本说明确认 7.0.2 于 2026 年 7 月 17 日发布。

这件事留给企业安全团队的压力很具体：漏洞研究已经跑到小时级，很多防御验证仍排在季度计划里。

01

不看更新记录，不翻 Git 历史，AI 直接审 WordPress 源码

任务开始前，几条容易“找答案”的路都被堵上了：删除.git目录，禁止模型查看更新日志和 Git 历史，也不能联网查找补丁。模型只能从当时的源码里寻找问题。

测试环境尽量贴近常见的 WordPress 与 MySQL 部署，攻击从未登录状态开始，不能依赖极端配置。模型给出的发现还要交给另一个对抗 Agent 复核。

4 个 Agent 同时分析不同方向。某条路线卡住就换方向，几条路线撞到一起，再由负责调度的 Agent 重新分配。第一轮没有结果，便继续下一轮。

找到 SQL 注入线索后，漏洞在原生 WordPress 环境中经过人工验证。确认漏洞成立，模型继续追踪远程代码执行路径。约 4 小时后，整条利用链得到验证。按订阅费用折算，整个任务成本约 25 美元。

研究原文记录：从 SQL 注入继续推演到 RCE，耗时约 4 小时；按订阅费用折算，成本约 25 美元

人的工作没有消失。目标怎么定、约束怎么写、结果是否可信、漏洞如何披露，都需要研究员把关。AI 压缩的是中间那段反复试错的时间。

wp2shell 公开后的第二天，OpenAI 又披露了一起内部评测事故。评测时未启用部分生产环境安全限制，GPT-5.6 Sol 和一款尚未发布的模型突破测试环境限制，访问了 Hugging Face 生产系统，并使用窃取的凭据和零日漏洞找到远程代码执行路径。

02

漏洞很快就能复现，企业修复还要走流程

企业内部的确认与变更需要时间，漏洞复现也可能在同一时间发生。研究原文提到，正式披露前已有其他研究人员独立复现完整链条，随后 GitHub 上也出现了 PoC。

企业内部需要时间，外部的利用却不会停下来等。这次研究用了约 10 小时走完整条漏洞链。细节公开后，复现代码和改造版本也可能很快出现。安全团队还在核对资产时，针对公网服务的扫描或许已经开始。

版本升级完成，只能说明补丁已经落地。补丁前入口是否被访问过、WAF 是否记录异常请求、主机上是否出现可疑进程、SIEM 里能否找到前后关联，仍要回到日志和检测结果中确认。这些信息，从一张“已修复”表格里看不出来。

WordPress 官方说明：本次安全更新包含 REST API 批量路由混淆与 SQL 注入导致的远程代码执行问题。

漏洞管理能说明补丁推进到哪一步。安全验证还要补上另一份记录：入口能否到达，防护设备是否发现，告警有没有进入 SOC，分析人员拿到的上下文够不够，修复后结果有没有变化。

03

补丁打完后，还得确认检测和响应是否生效

针对 wp2shell 这类事件，验证可以从关键行为入手：匿名访问批量 API、异常数据库查询、权限变化，以及代码执行后的进程和网络活动。场景在受控环境中逐层运行，分别观察 WAF、IPS、EDR 和 SIEM 的反应，既不触碰生产业务，也能保留每一层的检测、告警和处置结果。

一条新漏洞进入验证清单后，可以沿四段链路检查

暴露确认：受影响版本是否存在，批量 API 是否对公网开放，临时缓解措施有没有生效。

控制验证 ：WAF、IPS、EDR 能否识别关键行为，阻断和告警分别落在哪一层。

运营验证：日志是否进入 SIEM，SOC 能否关联上下文，处置责任能否落到具体人员。

修复复测：升级、临时规则和检测策略调整后，用同一场景重跑一次。

现场经常出现一种情况：WAF 有日志，EDR 没动静；SIEM 收到告警，却缺少前后请求；分析人员看见了异常，工单没有落到业务负责人。每个环节单独看都“有记录”，放到一条攻击链里就断了。

安全验证要找的就是这些断点。哪一层看见了，哪一层漏掉了，告警出来后有没有人接，修复完成后同样的行为还能不能走通。结果跑出来，团队才知道该改设备策略、检测规则，还是响应流程。

04

重大漏洞来了，验证很难再等到季度末

按季度做安全验证，过去没什么问题。设备和规则变化相对慢，一轮验证结束，结果还能用上一阵。

现在的情况有些不同。wp2shell 从源码研究到完整链条只用了约 10 小时，补丁、临时规则和检测策略又可能在几天内连续调整。刚跑完一次验证，环境已经变了。

一些团队开始把这类高风险事件单独留下来，整理成可以复跑的场景。设备升级后再看一遍，规则改过后再对一次，资产迁移也顺手复测。公网暴露、无需认证、可远程执行、影响核心业务的事件通常排在前面，普通问题仍照原来的流程处理。

时间一长，过去半年新增了哪些场景、哪里曾经失效、整改后有没有恢复，自然会形成一份记录。到了预算评审或项目续期，不用再靠任务次数解释，具体缺口和复测结果已经摆在那里。

AI 把漏洞发现压缩到小时级，企业排查、修复和复测的窗口也随之缩短。季度验证不会消失，但 wp2shell 这类高风险事件很难再等到季度末。目前最好的方式可能就是结合威胁情报实时更新、实时验证，首先确认防线在补丁打上去之前是不是能防得住。

参考来源Adam Kues：WordPress RCE 的 AI 辅助发现过程，2026-07-20。wp2shell 安全公告，2026-07-17。WordPress 7.0.2 Release, 2026-07-17.OpenAI，OpenAI and Hugging Face partner to address security incident during model evaluation，2026 年 7 月 21 日。