用途
本技能用于判断已核实的 WordPress 原语（primitives）是否真正组合成管理控制或良性代码执行证明。它是一道链式验证关卡，而不是在某个前提条件失败后强行升级的检查清单。
何时使用
- 插件漏洞已有精确版本与路由证据。
- 已批准身份可能拥有意外的 WordPress 能力。
- 上传或配置写入可能触达可执行处理。
- CORS、XML-RPC、暂存环境或源码暴露可能补足缺失的前提条件。
前提条件
- 对注册、认证、上传、写入与执行测试的明确授权。
- 已批准的合成账户与一次性内容。
- 精确的 WordPress、插件、主题与托管行为。
- 用于任何执行测试的良性标记。
- 清理与停止条件。
如何运行
构建前提条件表：
| 步骤 | 状态 | 所需证据 |
|---|---|---|
| 组件漏洞 | 已观察 | 精确版本与受影响操作 |
| 已授权身份 | 已确认 | 已批准账户与当前角色 |
| 写入或上传能力 | 未验证 | 合成工件被接受 |
| 可执行处理 | 未验证 | 良性标记被执行 |
| 管理控制 | 未测试 | 已批准的管理员专属操作 |
| 清理 | 已计划 | 工件与账户移除 |
不得越过未验证的前提条件继续推进。
流程
1. 确认组件
使用 hunt-wordpress 与 wordpress-plugin-hunt 确立：
- 来自多个信号的组件身份；
- 精确版本或提交；
- 易受攻击的路由或处理器；
- 认证与角色前提；
- 受影响的配置与文件类型。
公开的 readme 或过时资源本身并不充分。
2. 确认身份与能力
仅使用已批准的测试身份。记录当前角色以及该操作所检查的精确能力。订阅者、客户、作者、编辑与管理员角色不可互换。
不得用密码喷洒、撞库或无关的泄露凭据来弥补缺失的授权。
3. 用合成数据验证状态变更
使用唯一命名的合成文章、对象或惰性文件。记录：
- 请求与身份；
- 响应与结果对象 ID；
- 位置与内容；
- 预期授权策略；
- 清理结果。
如果对象无法安全移除，则在创建前停止。
4. 将上传与执行分离
被接受的上传仅证明上传边界。需单独确立可执行处理：
- 服务器将存储的扩展名映射到解释器；
- MIME 与扩展名验证允许所测试的类型；
- 存储路径可通过 Web 访问；
- 插件处理不会重命名或净化该文件；
- 良性标记可在已批准环境中执行。
切勿部署命令 shell 作为通用证明。
5. 评估管理影响
管理控制需要已批准的管理员专属效果，例如读取合成私有设置，或更改一次性配置值并恢复。用户枚举、REST 元数据或可用的登录页面并不构成账户接管。
6. 组装路径
使用 cross-attack-chains 仅连接已确认的转换。当 CORS 与 XML-RPC 是实际前提条件时，使用 wordpress-cors-xmlrpc-rce-chain，而不仅仅是同一安装上的额外发现。
注意事项
- 开放注册通常创建低权限角色。
- XML-RPC 方法存在并不等于有权调用该方法。
- 启用的 PHP 进程函数并不构成上传原语。
- 插件版本证据可能过时或被回移。
- 暂存站点可能使用独立数据库且无生产信任路径。
- 某个前提条件失败，即表明所提议的链在此终止。
验证
- 组件身份、版本、路由与前提条件均已确认。
- 已批准身份具备精确所需的能力。
- 状态变更使用合成资源并可逆。
- 上传与执行作为独立步骤演示。
- 管理影响使用已批准的一次性操作。
- 每个缺失步骤保持推断或未测试状态。