CRITICAL: WordPress Core CVE-2026-87902 Exploited for Unauthenticated RCE

Pour one out for anyone who spent Tuesday evening assuming WordPress 7.1.2 was just another routine maintenance release. It was not. It closed CVE-2026-87902, a critical unauthenticated file inclusion flaw in WordPress core, and attackers started throwing payloads at it the same day the patch shipped. By Thursday morning the attack volume had grown more than tenfold and public scanning tooling was already making the rounds.

This one earns your attention for a reason that has very little to do with the CVSS number, though the number is bad enough at 9.2 under version 4.0 of the scoring system. The reason is reach. WordPress runs a sizable fraction of the web, and the affected version range is not some narrow window of recent builds. It stretches from 4.7.0, which shipped back in 2016, all the way through 7.1.1. If there is a WordPress install somewhere in your environment that nobody has touched in years, congratulations, it is in scope.

What actually broke

The flaw lives in how WordPress resolves page templates. When WordPress decides which theme file should render a given page it calls get_page_template() and builds a filesystem path based in part on data an attacker can influence. That attacker controlled data was not constrained tightly enough before it got folded into the template path, which means a crafted request can smuggle directory traversal sequences into the resolution logic and convince WordPress to include a PHP file sitting well outside the active theme directories. No account, no authentication cookie, no administrator clicking anything, and no vulnerable plugin required. The CVSS vector reflects exactly that, network accessible with low complexity, no privileges, no user interaction.

File inclusion on its own is ugly. File inclusion that reaches remote code execution belongs to a different category of problem entirely, and that is where the preconditions come in. Two things need to be true to make the jump from reading a local PHP file to running attacker code. The active theme has to contain a top level directory whose name begins with "page-", something like page-templates, which is a perfectly ordinary convention in plenty of commercial themes. And there has to be a readable PHP file somewhere on the server that does something useful when it gets included. The file attackers have converged on is pearcmd.php, which ships with PEAR and sits at /usr/local/lib/php/pearcmd.php on a great many stock PHP installations. That combination has been a reliable bridge from file inclusion to code execution for years, and it is doing the job again here.

Those conditions are why some coverage has described this as conditional remote code execution, and that framing is fair as far as it goes. It is also the kind of nuance that gets people hurt. Neither precondition is exotic. A commercial theme with a page-templates directory and a distribution that dropped PEAR into the default include path is not an unusual server, it is a Tuesday.

The timeline is the problem

WordPress shipped 7.1.2 on September 22, 2026, along with backported fixes across two dozen older branches reaching down to 4.7.37. Exploitation attempts were recorded the same day. Researchers at Previdian counted 68 attempts beginning September 23 from source addresses in New Jersey and Indonesia, and the pattern moved quickly from reconnaissance, essentially probing whether a given target had the right theme layout, into genuine exploitation using pearcmd.php to write files to disk.

Those files are the clearest fingerprint available right now. Attackers have been dropping PHP into /tmp and /var/tmp with names like wp-pear-rce-flag.php and poc87902.php, which reads less like a careful operator and more like somebody running a proof of concept at scale to build a target list for later. Second stage payloads have been pulled from raw.githubusercontent.com, which is convenient for the attacker because outbound traffic to GitHub rarely raises an eyebrow inside a hosting environment. By September 24 the volume had multiplied roughly ten times over and had spread across a far wider set of sites, which is the shape of opportunistic mass scanning rather than anything targeted.

The gap between disclosure and mass exploitation here was measured in hours, not weeks. That is worth sitting with for a moment, because a lot of patch management programs are still built around the assumption that you have a comfortable window between a vendor advisory and real world attacks. That assumption has been wrong for a while and it was spectacularly wrong this week.

Who is actually exposed

There is good news, and it is worth stating plainly. WordPress enables automatic background updates for minor releases by default, and that single default has quietly rescued an enormous number of sites here. Most installs that were simply left alone have probably already taken 7.1.2 or the appropriate backport without anybody lifting a finger.

The bad news is the population that does not benefit from that default. Sites where auto updates were deliberately switched off, which is common in agency and managed environments where somebody wanted change control. Sites pinned to an old branch because a plugin or a theme broke on upgrade and nobody ever went back to fix it. Multisite networks where updates are gated behind an approval process. Development and staging copies that nobody remembers exist but that are still perfectly reachable from the internet. Every one of those is exactly the kind of asset that becomes the soft entry point into a hosting account, and none of them are going to patch themselves tonight.

Shared hosting deserves a specific mention. On a server where a single account can be compromised through this bug and pearcmd.php is sitting there readable, the blast radius depends entirely on how well the host separates tenants. Stack that against the cPanel privilege escalation flaw that surfaced in the same week and the picture for hosting providers gets uncomfortable quickly.

What to do about it

The remediation is refreshingly simple, which makes a nice change from the usual appliance hotfix scramble. Update to 7.1.2 if you are on the 7.1 line, or install the matching backport for whatever branch you are running, and then confirm the update actually applied rather than trusting the dashboard to tell you the truth. Verify instead of assuming, because the sites most likely to still be vulnerable are precisely the ones where something was already quietly interfering with the update mechanism.

If you genuinely cannot patch within the next few hours, a few things are worth doing anyway. Removing pearcmd.php or restricting read access to it breaks the most popular exploitation path without touching WordPress at all, and almost nothing in a modern deployment needs that file present. Auditing your active theme for a top level directory starting with "page-" tells you whether you meet the first precondition, which tells you how urgently to care. A web application firewall rule watching for traversal sequences in template related parameters buys a little time. None of that replaces the patch.

On detection, look backwards rather than only forwards. Any PHP file created in /tmp or /var/tmp on a web server is worth investigating on general principle, and the specific filenames noted above are a free win if they happen to be sitting there. Outbound requests from a web server to raw.githubusercontent.com deserve a second look, especially from a host that has no business pulling code from the internet at runtime. In access logs, hunt for requests carrying traversal patterns aimed at page template parameters, and pay attention to bursts from single source addresses, because this campaign has not been subtle about volume. If you do find evidence of successful exploitation, treat it as a full compromise of the hosting account rather than a stray file to delete, because anyone who landed code execution had the opportunity to plant persistence somewhere considerably less obvious than /tmp.

One more thing worth checking while you are in there. If a site was running an unsupported branch old enough that no backport exists for it, patching is not really the conversation anymore. Migration is.

The business angle

For MSPs this is the easiest patch management conversation of the quarter. Every client running WordPress on infrastructure you do not currently manage is a live demonstration waiting to happen, because you can show them a CVSS 9.2 unauthenticated code execution bug that went from disclosure to mass exploitation in under 48 hours and then ask who exactly was watching their site that night. Bundling WordPress lifecycle management, meaning version monitoring, tested update windows, and file integrity monitoring on web roots, into a managed web presence offering converts a recurring fire drill into recurring revenue.

The forgotten staging site angle sells external attack surface discovery and recurring vulnerability scanning better than any brochure you could write. Most clients genuinely do not know how many WordPress installs are answering on their domains, and the fastest way to prove the value of an attack surface assessment is to hand them a list they did not expect.