A critical vulnerability in WordPress core is being actively exploited in the wild, just hours after patches were released. Tracked as CVE-2026-87902 with a CVSS score of 9.2, the flaw allows unauthenticated attackers to achieve remote code execution on vulnerable WordPress installations — and threat actors wasted no time weaponizing it.
What Happened
On September 22, 2026, the WordPress security team released version 7.1.2 to address a path traversal vulnerability discovered by security researcher Robert Ressl. The flaw resides in WordPress’s page-template resolution logic — specifically the get_page_template() function — and allows an unauthenticated attacker to force the inclusion of a local PHP file located outside the active theme’s directories.
The vulnerability affects all WordPress versions from 4.7 through 7.1.1. Patches have been backported to older supported branches, with fixes available in versions 7.1.2, 7.0.6, 6.9.9, and 6.8.10.
What makes this incident particularly alarming is the speed of exploitation. According to researchers at Patchstack, the first exploitation attempt was recorded at 11:49 UTC on September 22 — the same day the patch shipped. By September 23, attack traffic had increased more than tenfold, with at least 68 documented exploitation attempts originating from IP addresses across the United States, Indonesia, and other locations worldwide.
How the Exploit Works
CVE-2026-87902 is a local PHP file inclusion vulnerability masked behind a path traversal bug. For exploitation to succeed, two preconditions must be met:
- The active WordPress theme (or its parent theme) must contain a top-level directory whose name starts with
page-— for example,page-templates. - A readable PHP file must exist at a known path on the server. Attackers have gravitated toward
pearcmd.php, the command-line utility bundled with PHP’s PEAR package manager.
When both conditions are present and PHP’s register_argc_argv setting is enabled — which is the default in many Docker PHP images and cPanel-based hosting configurations — an attacker can craft a request that tricks WordPress into including pearcmd.php. From there, the attacker instructs PEAR’s command-line tool to write a malicious PHP file to disk. Once that file is in place, accessing it through the web server executes arbitrary shell commands on the host.
Researchers observed a clear three-stage attack pattern in the wild: first, attackers probe the target to confirm it is vulnerable; second, they verify that pearcmd.php can be included; and third, they abuse PEAR’s file-writing capability to drop a web shell. Observed payload filenames include wp-pear-rce-flag.php, poc87902.php, and randomly named files such as luci_<random>.php and zeta_<random>.php. Some payloads were as simple as a PHP short tag that executes a shell command on access.
Patch-Diffing at Scale
One detail that underscores the evolving threat landscape: Patchstack analysts found that the malicious payloads closely mirrored the code changes visible in the patch diff. In other words, attackers reverse-engineered the fix to build their exploits rather than discovering the vulnerability independently. This technique — known as patch-diffing — is not new, but the turnaround time here was extraordinary. With the patch public and the diff readily available, threat actors had a working exploit within hours.
“Certain preconditions make exploitation less likely,” noted Ryan Dewhurst, founder of Previdian, referring to the theme-directory and PHP configuration requirements. “But given WordPress’s scale, even a small percentage of vulnerable sites represents an enormous attack surface.”
Who Is Affected
WordPress powers an estimated 40% of all websites on the internet. While the preconditions limit universal exploitability, the affected theme list is broader than it might appear. Legacy default themes such as Twenty Twelve and Twenty Fourteen meet the page- directory requirement, as do popular third-party themes including Neve, Hestia, and Sydney. Sites running PHP on Docker with default configurations or on cPanel-managed hosting with PHP versions prior to 8.5 are particularly at risk because register_argc_argv tends to be enabled by default in those environments.
WordPress’s built-in auto-update mechanism should protect many sites — minor security releases are applied automatically unless an administrator has explicitly disabled the feature. However, sites with auto-updates turned off, those running heavily customized environments where updates are tested before deployment, and sites maintained by agencies that batch updates on a monthly cycle may still be running vulnerable versions days after the fix shipped.
What to Do Right Now
Update immediately. If your site is running any WordPress version older than 7.1.2, update to the latest patched release for your branch. Verify the update applied by checking the version number in your WordPress admin dashboard under Dashboard → Updates.
Audit your theme. Check whether your active theme or its parent theme contains a top-level page- directory. If it does and you cannot update WordPress immediately, consider switching to a theme that does not meet this precondition as a temporary mitigation.
Check PHP configuration. Review whether register_argc_argv is enabled in your php.ini. Disabling it, if your application does not require it, eliminates one of the exploitation prerequisites. This is especially relevant for Docker-based and cPanel-hosted deployments.
Scan for indicators of compromise. Look for unexpected PHP files in /tmp, /var/tmp, and your WordPress root directory — particularly files named wp-pear-rce-flag.php, poc87902.php, or files matching the pattern luci_*.php or zeta_*.php. Review your web server access logs for unusual requests targeting template-related endpoints.
Use a web application firewall. Major WordPress WAF providers including Patchstack, Wordfence, and Sucuri have already deployed virtual patches to block exploitation attempts targeting CVE-2026-87902. If you run a WAF, ensure its rules are current.
What to Watch Next
The speed at which CVE-2026-87902 was weaponized reinforces a trend that has defined 2026: the window between patch release and active exploitation is shrinking to hours, not days. Defenders who rely on scheduled patching cycles are increasingly exposed to this gap.
Security teams should also watch for broader exploitation campaigns. While the current attacks appear opportunistic — scanning wide swaths of the internet for vulnerable sites — more targeted operations are likely to follow as sophisticated actors integrate this vector into their toolkits. Any WordPress site that was not patched within the first 24 hours should be treated as potentially compromised and subjected to a thorough forensic review.
The WordPress security team has not indicated whether further hardening of the template resolution logic is planned, but given the severity of CVE-2026-87902 and the real-world exploitation, additional defense-in-depth measures in future WordPress releases would not be surprising.
Leave a comment