WordPress 零日漏洞数小时内被武器化，暴露出更快的威胁差距

响应速度的差距是真实的

WordPress 于 2026 年 9 月 22 日为 CVE-2026-87902 发布修复补丁。当天上午 11 时 49 分（UTC），首批野外利用尝试便已出现。从公开修复到实战攻击之间的时间线，已从数天——甚至数周——压缩至数小时，而追踪该漏洞的事件记录为我们呈现了这种压缩是如何发生的迄今为止最清晰的图景之一。

这是一项 CVSS 评分 9.2 的严重漏洞，允许未经身份验证的攻击者在 WordPress 站点上实现远程代码执行。要成功利用该漏洞，必须同时满足两个条件：活动主题或子主题必须包含名称以"page-“开头的顶级目录，且服务器必须存在一个攻击者可引用的可读本地 .php 文件。/usr/local/lib/php/ 下的 pearcmd.php 就是这类在野外多次出现的文件之一。

当这些条件都满足时，利用链的工作方式如下：攻击者触发一个 page-template 解析函数，以包含服务器上的任意 PHP 文件。随后利用该文件将新的 PHP 有效载荷写入 /tmp/ 或 /var/tmp/。下一次请求则包含托管在 GitHub 上的 Webshell，使攻击者获得对已攻破站点的持久访问权限。

攻击如何展开

Previdian 的遥测数据显示，自 9 月 23 日起共追踪到 68 次利用尝试，源自包括新泽西州和印度尼西亚在内的 IP 地址。Patchstack 独立确认，恶意请求已从对无害核心文件的侦察探测升级为涉及 pearcmd.php 和磁盘文件写入的主动利用。

这些攻击期间写入的文件名自述着自己的故事：wp-pear-rce-flag.php、poc87902.php、luci 加随机后缀、zeta 加随机后缀。这些并非零散实验。它们表明存在协调一致、工具驱动的 Campaign，按照既定管道推进——探测、写入、链式利用、持久驻留。

涉及的 IP 地址跨越多个托管提供商和地理区域，这与攻击者 routinely 使用的分布式基础设施模式相符。引人注目的并非某个单一来源，而是整个操作的节奏。

前置条件很重要，但它并非护盾

Previdian 创始人兼 CEO Ryan Dewhurst 指出，双重前置条件使得利用的可能性低于典型的无身份验证 RCE。这一评估是准确的，但需要更细致的解读。

大量 WordPress 安装默认启用了自动更新，这意味着运行较新次要版本的站点无论运营者是否手动应用补丁都会受到保护。风险最高的站点是那些运行过时、不再受支持的版本的站点，或者主题本身包含以"page-“前缀命名的目录的站点——这种命名模式在自定义主题和第三方主题中都不罕见。

pearcmd.php 这一前置条件也值得在更广泛的背景下审视。该文件随 PHP 的 PEAR 软件包一起分发，而 PEAR 在许多 Linux 发行版上默认安装，尤其是那些使用较旧软件包管理器的发行版。运行标准 LAMP 堆栈的服务器在共享托管环境中比经过加固的 VPS 或云托管 WordPress 站点更有可能存在 pearcmd.php。这种倾斜意味着该漏洞对共享托管和遗留基础架构上的站点构成不成比例的风险——而这正是 Web 上通常打补丁最慢的那部分站点。

超越 WordPress 的影响

WordPress 支撑着约 40% 的互联网。即便一项漏洞需要前置条件才能利用，庞大的安装基数也意味着攻击面极其巨大。每一个符合条件且未打补丁的站点都可能成为入口，而已被攻陷的 WordPress 站点常被用于网络钓鱼、恶意软件分发和僵尸网络招募——其影响往往远超原始所有者本身。

此次事件的第二层效应在于它传递的关于漏洞响应当前状态的信号。当一项严重缺陷在数小时内从披露走向实战利用时，运营者拥有数天宽限期来测试和应用补丁的旧有假设已不再成立。对于高风险站点，补丁发布后的实际响应窗口可能以分钟计。

这种压缩还引发了关于漏洞披露本身应如何演变的思考。当前的模式——披露、修补、寄望运营者在时限内应用修复——假设的节奏已被威胁格局超越。自动化工具的进展快于手动补丁管理流程，而此次事件正是这一差距的活生生演示。

站点运营者现在应采取的行动

WordPress 已在其支持的各个分支发布补丁：版本 7.1.2、7.0.6、6.9.9 和 6.8.10。运行上述任一版本的站点应核实最新补丁是否已应用。运行不支持版本的站点应立即制定升级路线图。

运营者还应对 WordPress 安装进行两项特定指标的审计。首先，检查是否存在任何活动主题中含有名称以"page-“开头的目录。其次，核实服务器上可访问路径中是否存在 pearcmd.php 或类似的可调用 PHP 文件。若任一条件存在，在 WordPress 版本更新或配置变更之前，该站点应被视为处于风险之中。

事后审计同样重要。检查 /tmp/ 和 /var/tmp/ 中是否存在名称可疑的最近修改文件。查找利用链可能丢弃的未知 PHP 文件。审查 WordPress 登录日志以排查未经授权的访问。并扫描发往已知恶意域名的出站连接，特别是用于托管 Webshell 的 GitHub raw 内容 URL。

更大的图景

CVE-2026-87902 终将淡出头条。它确实是一项严重缺陷，但需要前置条件且仅针对明确界定的安装子集。然而它所揭示的模式并非短暂现象。一项严重漏洞在数小时内被武器化而非数天的速度，反映了攻击者能力的更广泛加速——安全行业正朝此方向努力，但尚未充分适应。

对于 WordPress 站点运营者而言，直接要点简明扼要：立即打补丁，审计主题目录名称，并假设从披露到利用的窗口比你想的更窄。整个生态需要正视一个现实：编写修复方案的人一直在与编写利用代码的人赛跑，而后者已经在短跑中胜出。