WordPress CVE-2026-87902 is being exploited. Patch today.

WordPress CVE-2026-87902 went from patch to shell in about 28 hours. WordPress shipped 7.1.2 on September 22 with a single fix: an unauthenticated path traversal in get_page_template() that, under specific server conditions, becomes remote code execution. CVSS 9.2. Patchstack logged the first probes at 11:49 UTC the same day — before most agencies had read the release notes. By September 23 the traffic was no longer reconnaissance. Attackers are writing PHP files to disk that run shell commands when anyone loads them.

What actually happened

The bug is in page template resolution. An attacker sends a request with a valid page_id and a poisoned pagename — percent-encoded traversal octets like %2e%2e or the double-encoded %252e%252e — which survive WordPress's sanitizer and then get decoded inside get_page_template(). The result: WordPress includes a readable local PHP file from outside the active theme directories.

On its own that is a file-read problem. The escalation to RCE needs two conditions to line up. The active theme has to contain a top-level page- directory, and PHP has to have register_argc_argv enabled so a query string arrives inside the included script as $argv. With both true, attackers reach PHP's pearcmd.php — typically at /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php or /usr/share/pear/pearcmd.php — and use its config-create behavior to write a file wherever they like.

The payloads are already boringly standardized. Patchstack observed wp-pear-rce-flag.php, poc87902.php, and randomized luci_<random>.php and zeta_<random>.php, dropped into /tmp and /var/tmp. BleepingComputer reports malicious volume rose roughly tenfold on September 23 once Nuclei templates hit circulation.

The official release backported the fix to every branch still eligible for security updates — down to 4.7. Anything older than 4.6 gets nothing.

Why this WordPress vulnerability matters for your business

The window here was not days. It was hours. That changes what "we patch promptly" has to mean.

Auto-updates are a hope, not a control. Minor-release auto-updates cover a lot of WordPress installs, but "a lot" is the problem. Managed hosts stagger rollouts. Sites with modified core, a failed cron, or disabled updates sit still. The only answer that counts is the version string your site reports right now: 7.1.2, or 7.0.6, 6.9.9, 6.8.10, or 4.7.37+ on older branches.

Your exposure depends on server config you probably never audited. register_argc_argv is off in sane PHP builds and on in plenty of shared hosting defaults. Whether a page- directory exists at your theme root is a decision some developer made years ago. Neither shows up in a plugin dashboard. Both decide whether you got read or owned.

Do the compromise check, not just the patch. Patching stops the next attacker. It does not remove a shell that landed yesterday. Grep your access logs for %2e%2e, pearcmd, +config-show and +config-create. List /tmp and /var/tmp for unexpected .php files. A file there is not a warning — it is evidence the chain completed.

If you can't patch this hour, block the pattern. Reject traversal sequences in pagename at the edge, and disable register_argc_argv. That breaks the pearcmd path specifically, which is the chain being used in the wild today.

We run this exact sequence for client sites: confirm the version, confirm the two server preconditions, sweep the logs, sweep the temp directories. It takes about twenty minutes per site and it is the difference between "we updated" and "we know."

Sources: WordPress 7.1.2 release, Patchstack, BleepingComputer.