授权验证 WordPress 核心 LFI 到 RCE 链式利用（CVE-2026-87902）：从页面模板解析到 pearcmd.php 的检测教程

在授权范围内评估一台可能受 CVE-2026-87902 影响的 WordPress 站点时，核心目标不是"打穿"目标，而是在不破坏业务数据的前提下，确认该路径遍历与本地文件包含（LFI）缺陷是否真实存在、能否按资料所述链式触发 RCE，并留下可被第三方复核的证据。根据搜索到的公开资料，CVE-2026-87902 是 WordPress Core 的未认证路径遍历 / LFI 漏洞（CWE-98），影响版本为 4.7.0 至 7.1.1，已在 7.1.2 及若干分支回补版本中修复，公开资料标注其 CVSS v3.1 为 9.2（Critical），并关联安全公告编号 GHSA-7hp8-65ch-5whp。本文按侦察、假设、受控验证、证据记录、风险判断与整改复测的顺序，演示一套以"存在性确认"为边界的检测方法；所有命令均使用占位目标，且仅覆盖授权检测与整改复测，不提供面向真实生产环境的攻击脚本。需要特别强调的是，下文引用的漏洞编号、受影响版本与修复版本必须以官方公告和权威漏洞库二次核验后再写入正式报告。

测试目标、授权范围与前置条件

在接触任何目标之前，先把范围和控制条件固定下来。这一步决定了后续每个动作是否合规、可审计。

明确授权与范围

• 书面授权：取得客户或资产所有方签署的测试授权书，写明目标域名 / IP、测试窗口、允许的测试强度，以及是否允许触及 RCE 验证层。CVE-2026-87902 的 RCE 环节会向服务器写入文件，必须在授权中单独确认是否获准执行到该层。
• 范围边界：明确哪些主机、路径、子站点在范围内。多站点（Multisite）环境下，LFI 的影响面可能跨站点扩散，需逐一确认。
• 紧急联络人与中止条件：约定一旦出现服务异常、数据风险或非预期告警时的中止流程与联系人。

搭建隔离靶场

公开资料显示，已有研究者在 Docker 环境中对 WordPress 7.1.1（存在漏洞）与 7.1.2（已修复）做了端到端复现。正式对客户资产操作前，应先在隔离靶场中验证检测流程：

• 用与目标版本一致的 WordPress 镜像复现，确认探测请求的"命中"与"未命中"特征。
• 靶场与生产网络隔离，避免探测流量误伤真实业务。
• 在靶场中演练清理步骤，确保 RCE 验证若写入文件后能被完整删除。

受影响版本的联网核验

资料给出的受影响区间为 4.7.0–7.1.1，修复版本为 7.1.2，并提到向下回补至 7.0.6、6.9.9、6.8.10 等分支，直至 4.7.37。由于版本信息具有时效性，必须以 WordPress 官方安全公告与权威漏洞数据库二次核验后，再把具体版本号写入报告，不能仅凭第三方工具页面的摘要下结论。

阶段一：侦察与指纹识别

侦察目标是判断目标是否落在受影响版本区间，以及是否满足链式触发所需的环境条件，而不是立即发送包含 payload 的请求。

识别 WordPress 版本

• 通过页面源码中的 generator meta 标签、/readme.html、静态资源版本查询串（如 ?ver=）等被动指纹，初步判断大版本。
• 版本信息常被安全插件隐藏或伪造，被动指纹只能作为假设，不能作为最终判断依据。

识别主题目录结构

根据搜索资料，这条利用链的真实起点，是主题中存在以 page- 开头的顶层目录（如 page-templates/）。在 linux 上，../ 的路径解析要求路径中每个组成部分都真实存在，因此主题目录结构直接决定遍历是否可行。资料点名了符合该条件的旧主题（如 Twenty Twelve、Twenty Fourteen）与若干流行主题（如 Neve、Hestia、Sydney）。侦察时应确认当前启用主题是否属于此类结构，这是后续假设能否成立的关键前提。

阶段二：假设与触发条件分析

把侦察结果整理为明确、可验证的假设，再逐条验证，避免盲目发包。

LFI 触发路径

资料指出，漏洞位于主题模板解析相关函数（locate_template / get_page_template）。WordPress 在处理 pagename 等参数时，会按 page-{value}.php 之类规则拼接模板文件名，若对该值的路径控制不当，攻击者可借助 ../ 遍历，使 include / require 包含服务器上已存在的任意 .php 文件。这是第一层影响：强制包含一个本地已存在的 PHP 文件。

从 LFI 到 RCE 的链式条件

第二层影响是条件性的 RCE。公开 PoC 的思路是借助 PEAR 组件中的 pearcmd.php 来写入或执行 PHP 代码。要让这条链成立，通常需要同时满足：

• 服务器安装了 PEAR 且 pearcmd.php 位于可被包含的路径下；
• PHP 配置（如 register_argc_argv）允许通过查询串向该脚本传递参数；
• Web 服务器与文件系统权限允许目标目录写入。

这些前置条件缺一不可，因此"存在 LFI"并不等于"必然可 RCE"。授权测试中应把二者分开记录：LFI 的存在性、RCE 链是否具备前置条件、是否实际达成命令执行。

阶段三：受控验证与最小化探测

验证阶段的原则是：用最小化、可解释、可回滚的请求确认存在性，一旦确认即停止，不做超出授权的进一步利用。

只做存在性确认的 LFI 探测

在隔离靶场或已获授权的目标上，优先选择包含一个"已知存在且无副作用"的本地文件作为判定依据，例如尝试包含目标已知的某个合法模板文件，观察响应长度、状态码或页面结构是否出现可区分的"命中"特征。判定要点：

• 命中与未命中应有稳定、可复现的差异（如响应体长度、特定渲染片段的出现与否）。
• 避免直接读取或输出 wp-config.php 等含敏感凭据的文件；如需验证敏感文件可达性，应与客户确认，并在证据中以文件可达性结论替代凭据明文。
• 对占位目标的请求形式示意（真实参数需按授权环境调整）：

# 仅示意：对占位目标发送一次最小化探测，观察响应差异
# target.example 为授权范围内的占位目标
curl -s -o /dev/null -w "%{http_code} %{size_download}n" 
  "https://target.example/?pagename=<经授权确认的最小化遍历测试值>"

上述命令只记录状态码与响应长度，不输出页面内容，用于比较"命中/未命中"的差异，尽量减少对日志和业务的干扰。

何时停止

• 一旦确认 LFI 存在（命中特征稳定复现），LFI 层验证即可停止。
• RCE 层验证仅在授权明确允许、且前置条件已确认具备时才进行；验证时只做"能执行"的最小证明（如执行一个无副作用的只读命令），不植入持久化 webshell、不创建管理员账户、不读取或外传业务数据。资料中提到的 weaponized 利用链（PEAR RCE、webshell、admin 创建、loot）不属于授权检测范围，应明确排除。

降低业务影响的做法

• 控制请求频率，避免触发 WAF 封禁或影响正常访问。
• 优先选择业务低峰时段，并提前知会运维，以便区分测试流量与真实攻击。
• 任何写入操作都要先记录写入前状态，确保可逆。

阶段四：证据记录与报告字段

证据的价值在于可被第三方独立复核。建议每条发现至少记录以下字段：

报告字段	说明
漏洞编号	CVE-2026-87902 / GHSA-7hp8-65ch-5whp，须经官方公告与漏洞库二次核验
目标标识	授权范围内的占位化目标标识与资产归属
受影响组件	WordPress Core 版本、启用主题及其目录结构
触发条件	主题是否含 page- 顶层目录、PEAR / pearcmd.php 是否可达、相关 PHP 配置
验证层级	仅确认 LFI / 确认具备 RCE 前置条件 / 实际达成命令执行
请求与响应证据	探测请求、响应状态码与长度差异、时间戳
影响评估	对应 CVSS 评分（资料标注 9.2）与业务实际暴露面
复现条件	复现所需版本、主题、配置与请求序列
清理步骤	若有写入，记录删除操作与验证结果

复现条件要写到他人可按步骤独立重现的程度；影响评估应结合目标实际环境，而非照搬通用评分。

阶段五：清理与风险判断

清理步骤

• 若 RCE 验证过程中写入过任何文件（如测试用的临时 PHP 文件），逐一删除并二次确认已不可访问。
• 记录清理前后的目录状态作为证据，避免遗留可被真实攻击者利用的文件。
• 通知运维检查相关访问日志，确认测试痕迹已知悉、无残留后门。

风险判断

• LFI 存在但不具备 RCE 前置条件：风险仍高（可能泄露敏感文件），但影响层级低于已达成 RCE。
• LFI 存在且具备完整 RCE 链：按未认证远程代码执行处置，优先级最高。
• 将判断结论与 CVSS 评分、业务暴露面结合给出修复优先级，而不是仅以评分一刀切。

整改建议与复测

升级为首选

最直接的修复是将 WordPress Core 升级到已修复版本。资料给出的修复版本为 7.1.2，并提到向 7.0.6、6.9.9、6.8.10 等分支的回补。实际升级目标版本应以官方公告为准核验后确定，升级后务必回归验证站点功能。

临时缓解与加固

在无法立即升级时，可考虑以下缓解方向（资料提到存在 Nginx、Apache、PHP 的加固规则，具体规则需结合环境测试）：

• WAF / Web 服务器规则：拦截针对 pagename 等参数的路径遍历特征（如 ../ 序列）。
• 禁用或移除 pearcmd.php：如服务器无需 PEAR，移除或限制其可访问性可切断 RCE 链的关键一环。
• 收紧 PHP 配置：评估关闭 register_argc_argv 等可被利用的选项对业务的影响后再调整。
• 文件系统权限最小化：限制 Web 进程对可执行目录的写权限。

任何缓解规则都应先在隔离靶场验证不误伤正常功能，再灰度上线。

整改复测

• 升级或加固后，用阶段三的同一套最小化探测流程复测，确认"命中"特征不再出现。
• 在修复版本靶场（如 7.1.2）中对照验证，确保检测用例在修复环境下稳定返回"未命中"。
• 把复测结果追加到报告的回归验证部分，形成从发现到闭环的完整链路。

最后再次提醒：本文所有版本号、修复信息与漏洞编号均来自公开检索资料线索，正式交付前必须以 WordPress 官方安全公告和权威漏洞数据库核验；检测动作必须严格限定在书面授权范围内，并以不破坏业务数据、可复核、可回滚为前提。