CVE-2026-87902 one month on: how to check if WordPress was hit by the pearcmd.php flaw

A month ago WordPress released version 7.1.2 to patch CVE-2026-87902, an unauthenticated path traversal in page template resolution with a CVSS score of 9.2. Analyses in English (Patchstack, Equixly, CrowdSec) emerged immediately. Here we translate it into a procedure: what to look for in logs, what to check in PHP, what to disable if you can't update straight away.

The flaw in brief

When WordPress needs to choose a page template, the get_page_template() function constructs the filename from the pagename parameter. The bug: that path skips the validate_file() check used elsewhere for the same type of filename, so a double-encoded traversal sequence (%252e%252e or similar) survives sanitisation and is then decoded by urldecode(), pointing to a file outside the theme folder.

By itself this is a local file inclusion: it reads or includes an existing PHP file on the server. It only becomes remote code execution (RCE) if three conditions are true together, according to Patchstack's analysis: the active theme (or parent theme) has a top-level folder starting with page-, the server has a "useful" PHP file present and readable — in the publicly demonstrated chain, PEAR's pearcmd.php — and PHP is running with register_argc_argv enabled, a condition that exposes the query string to the included script as $argv.

Affected versions: 4.7.0 through 7.1.1. Fixed: 7.1.2, 7.0.6, 6.9.9, 6.8.10, with backports back to 4.7.37, all released on 22 September 2026.

Who is exposed on the server side

Two environments appear in every analysis: the official PHP Docker images, where no php.ini is loaded and the compiled default leaves register_argc_argv enabled, and classic cPanel configurations with PHP prior to 8.5. Themes with compatible folder structures cited include Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney.

How to read web server logs

Patchstack has documented three stages of attack, each with a different log signature.

Stage 1 — reconnaissance. Requests that include a harmless core file to see if the site responds abnormally. The most common files: wp-links-opml.php, wp-includes/feed-rss2.php, wp-cron.php, wp-includes/functions.php, wp-login.php, install.php. Typical pattern:

GET /?page_id=<id>&pagename=templates%2f<traversal>wp-links-opml

Stage 2 — pearcmd verification. The request points to one of these three paths, which cover most distributions and container images:

/usr/local/lib/php/pearcmd.php
/usr/share/php/pearcmd.php
/usr/share/pear/pearcmd.php

with a +config-show parameter at the end of the query string.

Stage 3 — disk write. Same pattern, but with +config-create+<payload>+/tmp/<name>.php: this writes a PHP file with content controlled by the attacker.

To search Apache or Nginx logs, the two elements to combine are: the pagename parameter with encoded sequences (%2e%2e, %252e%252e, upper or lowercase) and the presence of the page_id parameter — which according to Patchstack almost always appears together, because without a valid page ID the request returns a 404 and the vulnerable code is never reached. A basic command:

grep -E "pagename=.*(%2e%2e|%252e%252e)" access.log | grep "page_id="

To be combined with a specific search for pearcmd and config-create in the same log file. It's worth noting that much of the observed traffic also uses POST requests, not just GET, because WordPress reads pagename from the request body in preference to the query string.

If positive findings emerge, the next step is to search for unexpected PHP files in /tmp and /var/tmp: observed filenames include wp-pear-rce-flag.php, poc87902.php and variants with the prefix luci_ or zeta_ followed by a random string.

Check and disable register_argc_argv

To find out if the directive is active in your environment, two options:

php -i | grep register_argc_argv

or, to verify the configuration actually used by the web server (which may differ from the CLI one), a minimal PHP script called via browser:

<?php echo ini_get('register_argc_argv');

According to PHP's official documentation, register_argc_argv defaults to "1" and is modifiable only at INI_PERDIR level — so it must be set in php.ini, in a .user.ini file or in the PHP-FPM pool configuration for the vhost, not in .htaccess. The same documentation notes that the directive is deprecated as of PHP 8.5.0.

To disable it, in php.ini:

register_argc_argv = Off

followed by a restart of the PHP-FPM service or web server, depending on the SAPI in use. On a PHP-FPM pool dedicated to the site, the same parameter can be set in the pool file (php_admin_value[register_argc_argv] = 0) without touching the global server configuration.

To be clear, as repeated by all sources consulted: disabling this directive only breaks the demonstrated PEAR chain. It does not fix the underlying file inclusion flaw, which remains exploitable for reading files if other valid targets exist on the server. The only real fix remains updating to WordPress 7.1.2 or the correct release for your branch, verifiable with wp core version from the command line or from Dashboard → Updates.

The scale of the problem one month on

The CrowdSec report, based on observation of its sensor network, recorded 30,813 unique IP addresses that sent requests matching the CVE-2026-87902 pattern in the five days following 23 September 2026, with 322,680 total signals in the same period. The same report notes that the number of distinct sources grew a hundredfold in five days, a sign that exploitation has shifted from a few operators to automatically scanning tools in public circulation — including a dedicated Nuclei template.

For those managing multiple WordPress installations on their own servers or shared hosting, the practical checklist remains: update to 7.1.2 or higher on every environment, including staging copies and container images that don't auto-update; check whether the active theme or parent theme has a folder starting with page-; verify the status of register_argc_argv on the PHP environment actually used by the site, not just from the command line; and, if the server experienced successful write attempts, search for suspicious PHP files in /tmp, /var/tmp and wp-content/uploads before considering the incident closed.