CISA has added WordPress CVE-2026-87902 to its Known Exploited Vulnerabilities catalogue and set 28 September 2026 as the fix date for United States federal agencies. The flaw affects WordPress 4.7.0 through 7.1.1 and was patched on 22 September in versions 7.1.2, 7.0.6, 6.9.9 and 6.8.10. Attackers began probing the same day.
What CISA’s Listing Requires, and From Whom
The deadline binds United States federal civilian agencies, not site owners generally. The Cybersecurity and Infrastructure Security Agency, the US government body responsible for federal network defence, added the flaw to its catalogue on 25 September 2026 under the entry name “WordPress Core Remote File Inclusion Vulnerability”, with a due date of 2026-09-28 recorded against it.
The listed required action is to apply the vendor fix while following Binding Operational Directive 26-04, the agency’s rule on prioritising security updates by risk, or to stop using the software. CISA’s public alert announcing the addition names the directive but states no date; the date appears only in the catalogue entry itself.
For everyone else the listing is a signal rather than an obligation. It is CISA’s formal statement that the flaw is being used against real targets, which is the point at which a fix stops being routine housekeeping. The agency used the same mechanism earlier this month against the Cisco ISE vulnerability, where the due date fell on 19 September.
WordPress Versions and Their Fixed Releases
Every WordPress release from 4.7.0 to 7.1.1 carries the flaw, a span of close to a decade. The patch shipped on 22 September 2026 and was backported to every branch still eligible for security fixes.
| Branch | Fixed version |
|---|---|
| 7.1.x | 7.1.2 |
| 7.0.x | 7.0.6 |
| 6.9.x | 6.9.9 |
| 6.8.x | 6.8.10 |
| 6.7.x and older, down to 4.7.x | Backported builds on each branch |
WordPress said the fix went “to all branches eligible to receive security fixes (currently through 4.7)”. The security firm IONIX puts the oldest patched build at 4.7.37; that figure appears in its advisory summary and not in WordPress’s own announcement. Sites with automatic background updates enabled received the relevant build without action, according to the WordPress 7.1.2 release notes. The flaw was reported by Robert Ressl and is tracked as CVE-2026-87902 and GHSA-7hp8-65ch-5whp.
Whether Your Site Is Actually Exposed
Three conditions decide how far an attacker gets, and most coverage of this flaw skips the middle one. Work through them in order.
- Your WordPress version: anything from 4.7.0 to 7.1.1 is unpatched. Check Dashboard, then Updates. If the version shown is 7.1.2, 7.0.6, 6.9.9, 6.8.10 or a later backported build on an older branch, the core fix is in place.
- Your active theme: the file-inclusion path only opens if the active parent or child theme contains a top-level directory whose name begins with page-, such as page-templates. SecurityWeek and IONIX both name Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney as themes with that structure. Those are examples, not a complete list, so inspect the theme folder rather than relying on the names.
- Your server configuration: turning file inclusion into code execution additionally needs a readable PHP file on the server that does something useful when included, plus PHP’s register_argc_argv setting switched on. The published attacks use PEAR’s pearcmd.php. Patchstack reports that register_argc_argv is on by default in the official PHP Docker images and in cPanel environments running PHP below 8.5.
The distinction matters. Meet condition two and an unauthenticated stranger can already make your site include a local PHP file of their choosing. Meet condition three as well and that becomes remote code execution, meaning the attacker runs their own commands on your server. A site on a patched version fails condition one and is safe regardless of the other two.
WordPress sites are more often attacked through add-ons than through core, as happened with the Rank Math plugin vulnerability that put more than two million installations at risk in 2024. This flaw is in core itself, which is why the version check comes first.
What the Attacks Have Looked Like Since 22 September
Exploitation began the same day the patch shipped. Patchstack, a WordPress security firm that watched the traffic through its own firewall, recorded the first attempt at 11:49 UTC on 22 September 2026, hours after the release went public.
The requests arrive in three stages: a probe to confirm that file inclusion works at all, a second pass checking whether pearcmd.php is reachable at one of its usual paths, and then an attempt to write a file into /tmp or /var/tmp. Filenames seen in the write attempts include wp-pear-rce-flag.php and poc87902.php.
Volume rose sharply on the second day. Patchstack described traffic on 23 September as running at more than ten times the level of the first evening, peaking around midday UTC before easing. Two user agents in that traffic, cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0, tell the firm that the exploit has been packaged into a scanning template rather than being hand-run by a few operators. The Hacker News counted 68 exploitation attempts by 23 September; that total comes from a single outlet and is not corroborated elsewhere.
Patchstack also noted that the payloads “match the exact encoding the patch addresses, so whoever built them was working from the diff rather than from an independent discovery” — in other words, attackers reverse-engineered the published fix.
Why Two Severity Scores Are in Circulation
You will see both 9.2 and 8.1 quoted for the same flaw, and both are correct under different scoring versions. The 9.2 rating comes from CVSS 4.0 and is the figure Patchstack, SOC Prime and SOCRadar use. IONIX cites the National Vulnerability Database’s CVSS v3.1 score of 8.1, rated High rather than Critical.
Neither score captures the conditional part. The scores describe the file-inclusion flaw itself, while whether it reaches code execution on a given site depends on the theme and server checks above.
What to Do if You Cannot Update Today
The update is the only complete fix, and the measures below reduce exposure without replacing it.
- Block traversal patterns: filter requests containing directory-traversal sequences in the page-template parameter at your web application firewall or CDN.
- Disable register_argc_argv: switch the setting off for web requests, which removes the published pearcmd.php route to code execution.
- Remove unused PEAR components: delete pearcmd.php and related PEAR files if nothing on the server needs them.
- Tighten filesystem permissions: restrict what the web server account can read, so fewer local PHP files are available to include.
- Then update: apply the patched build for your branch as soon as a maintenance window allows.
Sites that were unpatched while the scanning ran should also be checked for files written into /tmp and /var/tmp and for unexpected PHP files in the web root.
Where Things Stand as of 27 September 2026
As of 27 September 2026, patched builds are available for every supported branch, exploitation is continuing, and CISA’s due date for United States federal agencies falls the next day, 28 September. A proof-of-concept exploit is public, published by the same researcher credited with the report.
Two things remain unknown. Neither WordPress nor the security firms tracking the traffic has published a count of sites actually compromised, as opposed to probed, and no figure has been given for how many live installations meet the theme and server conditions needed for code execution.
Frequently Asked Questions
What Is WordPress CVE-2026-87902?
It is a flaw in how WordPress resolves page templates that lets an unauthenticated attacker make the site include a PHP file from elsewhere on the server. Under specific theme and server conditions it escalates to remote code execution. It affects WordPress 4.7.0 through 7.1.1.
Which WordPress Version Fixes It?
Update to 7.1.2 on the 7.1 branch, 7.0.6 on 7.0, 6.9.9 on 6.9 or 6.8.10 on 6.8. Older branches back to 4.7 received backported builds on 22 September 2026.
Is My Site Vulnerable if I Use a Block Theme?
The inclusion path needs an active theme with a top-level directory whose name starts with page-. Themes without such a directory do not open that path, but the safe answer is still to check the theme folder and update WordPress.
Does the 28 September Deadline Apply to Me?
Only if you run a United States federal civilian agency system. For everyone else the date is CISA’s internal remediation deadline, and the practical advice is to patch immediately because exploitation is already under way.
How Do I Tell if My Site Was Already Attacked?
Look for unexpected PHP files in /tmp, /var/tmp and the web root, and for requests carrying directory-traversal sequences in page-template parameters in your access logs. Filenames reported in the wild include wp-pear-rce-flag.php and poc87902.php.
