一个数学猜想提示词，变成了一篇安全研究
2026 年 7 月 20 日，Searchlight Cyber 旗下 Assetnote 团队的安全研究员 Adam Kues 发布了一篇研究报告：他用 OpenAI 最新模型 GPT-5.6 Sol Ultra 找到了 WordPress 核心中的一个预认证 RCE（远程代码执行）漏洞链。
这个漏洞链被命名为「wp2shell」。影响范围覆盖 WordPress 6.9.0 到 6.9.4 以及 7.0.0 到 7.0.1 版本。WordPress 团队在 7 月 17 日发布了紧急安全更新，罕见地采用了强制推送方式，即使用户未手动操作也会自动更新。
漏洞利用黑市上，这样一个可在未认证状态下远程执行代码的 WordPress 漏洞，报价约为 50 万美元。而 Kues 的整个研究成本——GPT-5.6 Sol Ultra 的 API 调用费——大约是 25 美元。
这个故事的技术细节、方法论意义和产业影响，值得逐一拆解。
从「循环双覆盖猜想」到零日漏洞挖掘
故事的起点是一个数学问题。
GPT-5.6 Sol Ultra 发布后不久，OpenAI 公开了一项成果：模型成功解决了「循环双覆盖猜想」（Cycle Double Cover conjecture）——一个存在了数十年的图论难题。更关键的是，OpenAI 同时公开了他们使用的提示词（prompt）。
Kues 注意到一个事实：这个提示词的核心设计——多智能体分工、多样化的搜索策略、持续的交叉验证——完全可以迁移到安全研究领域。用他的话来说：「如果这个提示词能解决困难的数学问题，它大概也足够好用来做安全研究。」
于是他把提示词做了针对性改造，指向 WordPress 的最新稳定版源码。具体的文件夹结构如下：
wordpress-ctf/
main/
# WordPress 源码
third_party/
# 留空，用于模型按需克隆依赖他移除了 .git 目录，并在提示词中明确要求模型：不得查阅变更历史、不得联网比对已修补版本。这是一个关键设计——LLM 在任务中倾向于「走捷径」找现成答案，而零日漏洞挖掘恰恰需要模型从第一性原理去理解代码。
提示词要求模型启动最多 4 个并行的「研究智能体」，覆盖输入解析、字符集处理、文件上传、错误处理、内置路由、序列化与反序列化、缓存、竞争条件、加密校验、类型处理、批量赋值等多个攻击面。智能体需要维护一个「方法族注册表」，防止多种搜索路径收敛到同一个方向上。当一个方向停滞时，模型会标记为「阻塞」，只在出现实质性新机制时才重新分配算力。
整个任务要求至少运行 6 小时。Kues 的实际执行时间约 10 小时，消耗了 GPT-5.6 Sol Ultra 订阅套餐周限额的 50%。按 $200/月的订阅价折算，约 25 美元。
一个偏移的索引，两个漏洞
回到办公室后，Kues 在模型的运行日志中看到了一条他起初完全不相信的结论：模型声称发现了预认证的 SQL 注入。
「WordPress 是这个时代最经得起考验的目标之一，本十年还没有出现过任何有意义的预认证漏洞。」Kues 在报告中写道。他架起一个干净的 WordPress 实例来验证——几分钟后，模型就从数据库中窃取了他设置实例时使用的管理员邮箱。
预认证 SQL 注入的根源在 WordPress 的 Batch API。
WordPress 5.6（2020 年引入）提供了 /wp-json/batch/v1 端点，允许用户在单次 HTTP 请求中批量发送多个虚拟 API 请求。正常的 API 请求会经过四步流水线：参数校验 → 参数净化 → 权限检查 → 端点回调。Batch API 的逻辑则不同：它将验证和执行分开成两个循环——先批量校验所有请求，再批量执行。
核心漏洞在 class-wp-rest-server.php 中的数组索引管理上。
$matches = array();
$validation = array();
$has_error = false;
foreach ( $requests as $single_request ) {
if ( is_wp_error( $single_request ) ) {
$has_error = true;
$validation[] = $single_request;
continue; // 注意：这里跳过了 $matches 的更新
}
$match = $this->match_request_to_handler( $single_request );
$matches[] = $match;
// ... 校验逻辑 ...
}当某个请求被判定为 is_wp_error() 时，$validation 数组会追加一项，但 continue 语句导致 $matches 数组未被更新。结果是：$matches 中每个索引对应的验证结果向后偏移了一位。这可以直接绕过任意 Batch API 端点的参数净化。
第二个漏洞则藏在一段普通的帖子查询代码中：
if ( ! empty( $query_vars['author__not_in'] ) ) {
$author__not_in = implode( ',', (array) $query_vars['author__not_in'] );
$where .= " AND {$wpdb->posts}.post_author NOT IN ($author__not_in) ";
}如果 author__not_in 参数传入的是数组，每个元素会被 absint 过滤为整数。但如果传入的是标量字符串（如 "foobar"），它会直接拼入 SQL 语句——完全没有转义。通过 Batch API 的验证偏移漏洞，可以绕过前端参数的类型限制，将一个任意字符串注入到 SQL 查询中。
但这里有一个问题：Batch API 并不支持 GET 请求，而这个 SQL 注入点只在 GET 端点上有效。模型给出的解决方案出人意料地巧妙——递归调用 Batch API 自身。内层 Batch 请求的请求方法验证也是通过参数验证实现的，而同样的验证偏移漏洞可以绕过方法校验。最终的攻击载荷是一个用双层 Batch 调用包裹的 GET 请求，成功实现预认证 SQL 注入。
从只读 SQL 注入到代码执行
拿到了 SQL 注入之后，真正困难的工作才刚刚开始。这是一个 UNION 型只读注入，能读取数据但不能写入或修改。
模型的后续利用链条之复杂，以至于 Kues 承认：「模型只用了 4 小时来编写这个利用链，但我花了整整一天才完全理解它在做什么。」
这个利用链包含以下步骤：
第一环：缓存投毒。 WordPress 维护着一个请求生命周期的内存对象缓存。通过 SQL 注入返回伪造的帖子数据，这些数据会被缓存到内存中。由于 WordPress 在渲染帖文时会进行预处理，攻击者可以在内存中「注入」一个完全假冒的 WP_Post 对象。
第二环：Embed 持久化。 WordPress 的 embed 功能允许在文章中嵌入其他帖子的内容。当 embed 的目标是本地帖子时，WordPress 不会实际发起 HTTP 请求，而是直接从数据库读取缓存数据。更关键的是，embed 缓存会在数据库层面持久化为 oembed_cache 类型的帖子。攻击者利用这一点，在数据库中创建了三个 oembed_cache 行（标记为 O、C、D）。
第三环：customize_changeset 与权限提升。 WordPress 的「主题定制」功能使用 customize_changeset 类型的帖子来存储对网站设置的差异（diff）。当变更发布时，WordPress 会临时将当前用户设置为 user_id 中指定的用户。利用缓存不一致性，攻击者可以篡改 C 的帖子类型为 customize_changeset，并包含一条以管理员身份执行的操作。
第四环：循环检测的利用。 WordPress 不允许帖子层级出现循环引用。当检测到循环时，WordPress 会调用 wp_update_post() 将父级 ID 置零。由于内存缓存与数据库不一致，攻击者可以控制这个 wp_update_post() 调用中的 post_content 字段——这恰好是一个 customize_changeset 的 JSON 数据。
第五环：Hook 调度与重放。 WordPress 在帖子发布时会调用动态 action hook："{$new_status}_{$post->post_type}"。攻击者构造了一个状态为 parse、类型为 request 的帖子 D，触发 parse_request hook——这会让 WordPress 从头重放整个 Batch API 请求。而此时，攻击者已经通过之前的 customize_changeset 机制暂时拥有了管理员身份。
第六环：创建管理员账户。 在第一次 Batch API 调用中，攻击者已经附带了一条「创建新管理员」的请求。这条请求在第一次轮次中会因为用户是未认证游客而失败。但在第二次轮次——由于 parse_request 重放了请求，且攻击者已经拥有了临时管理员权限——同一个请求成功执行，一个全新的管理员账户被创建出来。
此后，攻击者可以用这个管理员账户登录，上传一个包含后门的 ZIP 插件包，获得完整的服务器代码执行能力。
「没有一个安全研究员能在 10 小时内完成这个工作」
Kues 在报告中对 GPT-5.6 Sol Ultra 的能力给出了一个相当具体的评价：他使用过从 ChatGPT 时代开始的所有主流模型，GPT-5.6 在安全研究能力上相比 GPT-5.5 是一个显著的跃升。
「我不做一般性的断言，但我可以完全确定地说：没有一个安全研究员能在没有 AI 辅助的 10 小时内发现并完成这个利用链。即使我把第一个漏洞告诉他们，让他们在此基础上往 RCE 做，我也不确定能否在这个时间框架内完成。」
这个判断的核心依据是：整个利用链涉及到了 WordPress 代码库中至少 6 个完全不相关的子系统的组合——Batch API 的验证机制、帖子查询的参数处理、内存缓存、Embed 缓存、主题定制变更集、循环检测逻辑、动态 Hook 调度。这些机制各自的实现细节分布在不同文件中，没有单一的「关键函数」可供追踪。
传统的安全研究方法依赖于研究员的经验和直觉，在庞大的代码库中定位薄弱环节。而 LLM 的方法恰恰相反——它可以在全部代码上维护一个「理解上下文」，然后将不同子系统之间的交互作为搜索空间逐项测试。
成本对比：25 美元 vs 50 万美元
如果忽略技术细节，最能说明问题的一个数字是成本。
漏洞利用黑市上，一个针对 WordPress 核心的预认证 RCE 漏洞的报价约为 50 万美元。这不是一个新现象——Zerodium、Crowdfense 等合法漏洞经纪人长期公开悬赏此类漏洞。WordPress 覆盖了全球超过 5 亿个网站，其预认证 RCE 的利用价值不言而喻。
而 Kues 的搜索成本是 25 美元——大约相当于一个人一周的咖啡开销。
当然，这个成本对比并不完全公平。25 美元是模型的 API 调用费用，没有计入 Kues 的模型选择判断、提示词工程和对结果的验证时间。但即使考虑这些因素，AI 辅助漏洞研究的成本效率仍然比传统人工挖掘高出数个数量级。
一个更值得关注的趋势是：CVE 披露数量正在加速增长。VulnCheck 在 2026 年 5 月发表的分析报告指出，AI 辅助漏洞发现已成为公开 CVE 数量激增的主要驱动力。Tenable 在 2026 年 5 月的报告中预测，全年 CVE 披露量将达到 59,000 个，而 NIST 的 NVD 数据库已经大幅缩减了每个 CVE 的元数据补充工作。AI 发现的漏洞太多，人工分析跟不上了。
防守方的困境
这个故事的另一个侧面是防守方的应对时间窗口。
WordPress 团队在接到 Kues 的报告后发布了紧急安全更新（WordPress 6.9.5 和 7.0.2），并采取了强制自动更新策略。Kues 和团队也推迟公开披露，给管理员一个周末的窗口期来升级。
但问题在于：在一个 AI 可以在数小时或数天内发现可利用漏洞的世界里，这个窗口期正在缩短。如果攻击者也能访问相同水平的 AI 模型——考虑到 GPT-5.6 是公开可用的 API 服务——防守方的有效应对时间可能从数周压缩到数天甚至数小时。
这个不对称性体现在技术层面和经济层面。防守方需要为全球 5 亿个网站逐一部署补丁；攻击方只需要找到一个可利用的目标。
Kues 也给出了他判断的结论：「随着模型越来越强，安全研究将变得更像高层决策——选择什么产品和攻击面、研究多长时间、在提示词层面如何引导方向、在模型偏航时如何纠正。这些元技能目前 AI 还处理得很差，它们将变得越来越重要。」
产业影响与未回答问题
wp2shell 事件是 AI 辅助漏洞发现领域最具标志性的案例之一。原因在于它触及了软件安全生态的核心经济模型。
几个值得持续观察的问题：
- 漏洞市场价格的传导效应。 如果 AI 辅助发现大幅降低了漏洞挖掘的边际成本，黑市价格是否会下行？还是会因为利用链的复杂性和定制化而维持高位？目前没有可靠数据来判断。
- 主动防御工具的加速。 微软、Google、Anthropic 等公司已将 LLM 用于代码审计和模糊测试。这场攻防两侧的 AI 军备竞赛中，哪一方的技术进步更快，取决于微调数据、计算资源和工程投入的分配。
- 软件供应链的不对称风险。 WordPress 因其巨大的安装量和核心代码的稳定性，是漏洞挖掘的「高价值低风险」目标。其他拥有类似特征的软件——如 PHP、MySQL、OpenSSL——可能成为下一波 AI 辅助挖掘的目标。
Kues 在报告中提到，Calif 和 Hacktron 在他推迟披露的窗口期内独立复现了整个利用链。这说明 wp2shell 的发现是 GPT-5.6 可重复、可验证的方法论成果。
这个方法论的核心是任务构造——如何将安全研究问题分解为 LLM 能够有效处理的子问题，如何设计搜索空间的探索策略，如何防止模型「走捷径」产生虚假确认。Kues 从 OpenAI 的数学猜想提示词中移植过来的多智能体分工框架，本质上是一个元策略：与其让 LLM 做一次性的回答，不如让它作为一种「计算资源」来组织持续的安全搜索。
这个思路的影响范围远不止 WordPress 或 Web 安全。任何需要在大规模代码库中寻找异常模式的领域——固件安全、协议实现分析、密码学原语检查——都可能受益于类似的范式。
参考链接
- Adam Kues / Searchlight Cyber — wp2shell: WordPress 预认证 RCE 利用链研究（2026-07-20）
- OpenSSF — AI 与安全研究：漏洞发现的经济学影响
- WordPress 安全公告 — 6.9.5 与 7.0.2 紧急安全更新（2026-07-17）
- 独立复现团队 Calif & Hacktron — wp2shell 利用链验证分析
- Hacker News 讨论 — “Exploit brokers pay $500k for WordPress RCEs”（48975665）
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
