摘要

WordPress 解析页面模板的调用链从未验证所选文件是否仍位于主题根目录内：

1. pagename 和 page_id 是公开查询变量，WP::parse_request() 会从匿名 POST 请求体中接受它们。
2. pagename 中的双重编码路径遍历在早期查询清理中作为转义的 %xx 字节存活下来（wp_basename() 无法将 %2f 识别为分隔符，而 sanitize_title_with_dashes() 有意保留有效的字节）。
3. 随后一个有效的 page_id 会选中一个真实已发布的页面，而恶意的 pagename 仍保留在查询对象中。
4. get_page_template() 稍后对该值调用 urldecode()，并将诸如 page-templates/../../../../../../../usr/local/lib/php/pearcmd.php 的候选项添加到模板层级中。
5. locate_template() 和最终的模板加载器仅检查存在性、可读性以及 .php/.html 后缀——从不检查规范化路径是否仍位于允许的主题根目录内——然后 include 它。

这就是 WordPress Core 中的一个未认证远程本地文件包含原语。在测试的官方运行时（wordpress:php8.3-apache，它捆绑了 PEAR 且不加载 php.ini，因此 register_argc_argv 为 On）上，该包含被链接到 PEAR 的 pearcmd.php：第一个匿名请求使 config-create 将攻击者控制的 PHP 写入 /tmp，第二个匿名请求包含该文件并以 www-data 身份执行它。

Core 中缺失的路径包含检查才是漏洞所在。PEAR 只是从文件包含到代码执行的其中一条依赖环境的路径——它不是 WordPress 的依赖项，也并非在每个部署中都存在或可用。

根本原因

已验证的源代码位置（WordPress 7.0.2）：

前提条件

独立的文件包含原语需要：

所演示的 PEAR 阶段还需要一个可读的 pearcmd.php（及其依赖项）、Web SAPI 的 register_argc_argv=On，以及一个可写的输出目录。生产环境的 php.ini 文件设置 register_argc_argv=Off；测试镜像不加载 php.ini，因此编译默认值（On）生效。这是对所演示代码执行链普遍性的重要限制。

捆绑的 Twenty Twenty-Three/Four/Five 主题不附带顶层 page-* 目录，因此原版实验环境需要下文描述的夹具。自定义主题可以合法地使用 page-templates/ 布局（WordPress 文档）。

公告记录了这些条件在已发布软件中出现的位置：主题条件由旧版 Twenty Twelve 和 Twenty Fourteen 主题以及 Neve、Hestia 和 Sydney 等第三方主题满足，而 PEAR 转换适用于官方 PHP Docker 镜像以及运行 PHP 8.5 以下版本的默认 cPanel 配置。（Twenty Twelve 和 Twenty Fourteen 都附带顶层 page-templates/ 目录；其余陈述来自公告。）本仓库未测量完整链条的适用频率。

快速开始

cve-2026-87902.py 需要 Python 3.6+（仅标准库），默认访问实验环境 http://127.0.0.1:8091。预期输出：

成功时退出码为 0，否则为 1，因此该 PoC 也可用作回归/检测检查。

清理：docker compose down -v。

验证结果

2026-09-22 针对本实验环境运行（Docker 29.4、OrbStack、Apple silicon）：

证明工件是容器内的 /flag，由 root 拥有且全局可读（root:root，权限 0444）。它证明以 Web 服务器账户身份执行 PHP 并访问文件；它不是提权目标。

链条如何工作

两个匿名 POST。WordPress 路由值在表单体中传递，PEAR 参数在原始查询字符串中传递（PHP 将原始查询字符串按字面 + 拆分为 argv，且不对各个参数进行 URL 解码）：

阶段 1 — 包含 pearcmd.php 并写入载荷：

阶段 2 — 包含生成的文件并运行其 PHP：

关键细节：

• 两层编码。 请求体被 PHP 解码一次为 templates%2f%2e%2e%2f...；清理器保留这些字节，只有 get_page_template() 后期的 urldecode() 才将它们转换为 / 和 ..。
• page- 前缀。 WordPress 会在值前面加上 page-，因此夹具目录 page-templates/ 对应开头的 templates 段。
• 强制 .php 后缀。 候选项是 page-<decoded>.php，这就是目标不带后缀给出的原因（.../pearcmd、/tmp/wp-pear-rce-flag）。
• POST 而非 GET。 redirect_canonical() 跳过非 GET/HEAD 请求，而表单体让查询字符串只携带 PEAR 参数。
• 无引号载荷。 wp_magic_quotes() 也会作用于 $_SERVER，因此服务器构建的 argv 被转义，PEAR 稍后会规范化反斜杠。已验证的载荷使用 chr() 且不包含引号字符。（它简化为 <?=file_get_contents('/flag')?>。）
• config-create 根路径。 PEAR 拒绝相对根路径（Root directory must be an absolute path beginning with "/"），因此载荷被注入为根路径本身。
• 深度。 cve-2026-87902.py 遍历 .. 段直到路径遍历到达目标（本实验环境布局为 7，可用 --depth 固定）。

实验环境

lab/up.sh 执行三个步骤，可安全重复运行：

1. docker compose up -d --build --wait — 固定 wordpress:7.0.2-php8.3-apache 加 mysql:8.4，端口 127.0.0.1:8091（仅回环）。
2. 如果站点尚未安装，则运行 WordPress 安装程序（admin / adminadmin）。
3. 在活动主题内创建夹具并打印它：wp-content/themes/twentytwentyfive/page-templates/，root:root，权限 0755，空。

实验镜像显式添加 register_argc_argv=On（lab/Dockerfile），而非依赖编译默认值，并内置 /flag（root:root，权限 0444，内容 CVE-2026-87902-POC-OK）。

滚动标签 wordpress:php8.3-apache 不适用于本实验环境：该漏洞在 7.1.2 中已修复，未固定的标签会静默地将实验环境变为已修补状态。

阴性对照与限制

已验证或已记录的对照：

• 主题中没有顶层 page-* 目录 → 固定前缀无法被移除，路径遍历永远不会开始（已验证：移除夹具 → 无标记）。
• register_argc_argv=Off → 没有 PEAR 写入器，但文件包含原语仍然存在。
• PEAR 或其依赖项缺失 → 没有写入器。
• .. 段数量错误 → 未到达目标（已验证：深度 1-6 和 8-12 在实验环境中不产生标记）。
• 为页面分配了自定义页面模板 → 排序在恶意候选项之前并胜出。
• 无后缀文件（例如 /flag）无法直接读取——候选项会被追加 .php。
• 拒绝请求目标中原始 <、>、= 字节的 WAF/CDN/反向代理会破坏 PEAR 参数通道（因部署而异）。
• open_basedir/MAC 限制或不可写的输出目录会破坏链条；/tmp 上的 noexec 不会（PHP 读取并解释该文件）。

本 PoC 复现了一个已验证的配置。它并不声称每个 WordPress 安装都可被利用，也不测量普遍性。

修复建议

• 升级到 WordPress 7.1.2 或更新版本（或您所在分支的补丁版本）。
• 模板处理的纵深防御：解码后，拒绝路径遍历和绝对路径候选项（例如 validate_file()），并在包含已定位模板之前，将候选项和主题根目录的 realpath() 与末尾目录分隔符进行比较。
• 运维缓解措施：为 Web SAPI 设置 register_argc_argv=Off，从生产镜像中移除未使用的 Web 可读 PEAR 入口点，审计子主题和父主题中的顶层 page-* 目录，并限制 PHP 账户的写访问权限。

文件

披露时间线

该报告在初始分类被修订后被接受为有效的安全发现；通信记录未注明该接受的日期。

免责声明

本仓库出于防御和研究目的发布。仅对您拥有或明确授权测试的系统使用它。实验环境绑定到 127.0.0.1，不得暴露给不受信任的网络。

许可证

MIT — 参见 LICENSE。引用元数据位于 CITATION.cff：

Ressl, Robert (2026). CVE-2026-87902 PoC: unauthenticated path traversal in WordPress page-template resolution (v1.0.0). https://ressl.ch

漏洞报告和本 PoC 在组织和一致性审查方面借助了 AI 协助；研究人员对技术主张负责。