27 SEP 2026 — WordPress patched a critical file-inclusion flaw in core on 22 September, and attackers were testing sites for it the same day. Every release from 4.7.0 to 7.1.1 is affected.
The United States cybersecurity agency added it to its list of exploited vulnerabilities on 25 September and gave federal agencies until 28 September to fix it.
What the flaw does
CVE-2026-87902 sits in get_page_template(), the WordPress function that decides which template file renders a page. WordPress's advisory says an unauthenticated attacker can make it include a chosen readable local PHP file from outside the active theme's directories.
That is file inclusion, not code execution by itself. WordPress rates it critical at 9.2 on version 4 of the scoring system and credits Robert Ressl with reporting it.
The fix went to 25 release branches at once, from 7.1.2 down to 4.7.37. The release note says sites that support automatic background updates will begin updating automatically, which covers many small sites and leaves out any that switched updates off.
When it becomes code execution
Two conditions turn the inclusion into code execution, and the advisory names both.
The active theme needs a top-level directory whose name starts with page-, such as page-templates. WordPress lists its own older default themes Twenty Twelve and Twenty Fourteen, and the third-party themes Neve, Hestia and Sydney.
The server also needs a readable PHP file that can be abused once included. The advisory's example is pearcmd.php, part of the PEAR package manager, which becomes dangerous when the PHP setting register_argc_argv is on. WordPress says that setting is the default in official PHP Docker images and in older cPanel configurations, which are two of the most common ways small sites are hosted.
A site missing either condition gets file inclusion without a route to code execution. A site with both gets the full attack.
How fast the probing started
Patchstack, a WordPress security company, recorded the first exploitation attempt at 11:49 UTC on 22 September and the first attempt to write a file through pearcmd.php at 15:34 UTC the same day. By 23 September, its security research lead, Dave Jong, says public scanning tooling was in circulation, including a template for the Nuclei scanner.
The attempts wrote payloads into /tmp and /var/tmp under names including wp-pear-rce-flag.php and poc87902.php, and some announced themselves with user agents such as cve-2026-87902-poc/1.0.
Nobody has published a count of compromised sites. What is on record is attempts, not successes.
The August wave of five critical WordPress flaws that needed no account was in plugins, which site owners choose to install. This one is in core, which every WordPress site runs.
Two severity scores for one bug
The CISA alert names it a remote file inclusion vulnerability, and the catalogue entry says it leads to remote code execution, no conditions attached. WordPress calls it the inclusion of a local file, one that reaches code execution only where the theme and server line up.
The scores differ too. WordPress's 9.2 is on the version 4 scale. The only score on the national vulnerability database record, supplied by a secondary scorer, is 8.1 on version 3.1, rated high rather than critical because it marks the attack complexity as high. That vector, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, can be entered into our CVSS 3.1 base score calculator to see where the difference comes from.
Neither score is wrong. They weigh the preconditions differently, and the version 3.1 figure treats them as a reason the attack is harder.
What to check on a site
Start with the version. Anything on 7.1.2, or the patched release of an older branch, is fixed.
Patchstack's advice for sites that cannot update at once is to reject traversal sequences in the pagename value of incoming requests and to switch off register_argc_argv. It also suggests searching access logs for %2e%2e, pearcmd, +config-show and +config-create, and checking /tmp and /var/tmp for PHP files nobody put there.
CISA's catalogue entry marks this one for forensic triage, so agencies are expected to look for signs of compromise as well as patch. The same check makes sense for anyone running an exposed site on an old version between 22 September and the day it updated.
View author profile → · Editorial policy
