CVE-2026-87902: A Critical WordPress Core RCE Flaw Under Active Attack

WordPress patched a critical core vulnerability on September 23, 2026, and attackers started probing for it within hours. By the end of the following week, one security firm had logged over 322,000 exploitation-pattern requests across its network, and another tracked more than 30,000 distinct attacking IP addresses in just five days. This one is different from the plugin vulnerabilities we usually cover here. It lives in WordPress core itself, affects every version back to 4.7.0, released in 2016, and needs no plugin at all to be exploitable.

What CVE-2026-87902 actually is

The flaw sits in how WordPress core resolves page templates. According to WordPress's own security advisory, if the top-level directory name of your active theme, or a child theme, starts with the prefix page-, and a specific PHP setting called register_argc_argv is enabled on the server, an unauthenticated attacker can manipulate that template resolution into a path traversal, pointing WordPress at an arbitrary local PHP file to include and execute. WordPress's own advisory names pearcmd.php as a real-world example of a file commonly present and abusable this way.

Security researcher Robert Ressl reported this privately through HackerOne on July 20, 2026, and WordPress acknowledged it the next day. That two-month gap between private disclosure and a public patch is actually the system working as intended, giving WordPress time to fix something this severe quietly before anyone outside the process knew it existed.

The detail that makes this relevant to exactly the setups this site covers

Here is what I think matters most for anyone reading this site specifically. WordPress's own advisory states plainly that the official PHP image for Docker has register_argc_argv enabled, and so does the default cPanel configuration on any PHP version before 8.5. Those are not obscure, rare configurations. A Docker-based WordPress deployment, exactly the kind of setup we have covered building in our posts on Docker healthchecks and reverse proxy configuration, and a typical shared or budget VPS host running cPanel, are both squarely in the affected category by default, not as an edge case.

Who is affected, and what the fix is

Every WordPress version from 4.7.0 through 7.1.1. WordPress fixed it in version 7.1.2, and because of the severity, backported the patch all the way down through every older branch back to 4.7, which is unusually broad backport coverage and a sign of how seriously the project treated this one.

Update to 7.1.2, or confirm your current version has received the backported patch if you are deliberately running an older branch for compatibility reasons. If you manage several WordPress sites, I would check every single one today, not just the ones you remember updating recently, since this affects the oldest supported branches just as much as the newest.

What to check if you suspect you were already hit

Patchstack's observed exploitation attempts have included requests trying to include ordinary WordPress core files, apparently used by attackers to fingerprint which sites are actually vulnerable before a real payload. Later activity has included a write-to-disk stage, meaning a successful exploitation can leave a file on your server as proof the site is compromised, sometimes just a marker string confirming exploitability for later use.

Check your server's access logs for unusual requests referencing page-template paths or attempts to reach files like pearcmd.php through unexpected parameters. Look for any new or unexpected files in your webroot you cannot account for, and treat any you find as a sign of compromise, not just a missing patch.

A real mitigation if you cannot update immediately

WordPress's own advisory and multiple researchers note that disabling register_argc_argv on the server, outside of WordPress itself, blocks this specific attack path even on an unpatched version. This is not a substitute for updating. Robert Ressl, the researcher who found this, has been explicit that server-level hardening like this only reduces exposure, it does not fix the underlying WordPress vulnerability. Treat it as a stopgap while you get the real update applied, not a reason to delay the update itself.

The catch: this is the second core-level WordPress RCE chain this year

I do not want to present this as an isolated event, because it genuinely is not. Earlier in 2026, a separate core vulnerability chain known as wp2shell, tracked as CVE-2026-63030 and CVE-2026-60137, also enabled unauthenticated remote code execution against default WordPress installations with no plugins required. Two unrelated, no-plugin-needed, critical severity core chains in the same year is a real pattern, not a coincidence worth dismissing. If you manage WordPress sites professionally, I would treat core version currency as seriously as you treat plugin updates, not as the safer, more stable layer you can check less often.

FAQ

Do I need a specific plugin installed to be vulnerable to this?
No. This lives entirely in WordPress core's template resolution, which is exactly what makes it more dangerous than a typical plugin vulnerability. Every WordPress install has the affected code path, regardless of which plugins you run.

Is my site safe if I am running the latest version?
If you are on 7.1.2 or later, yes, for this specific vulnerability. I would still check your server logs for pre-patch exploitation attempts if you only updated recently, since the window between disclosure and your actual update matters.

What is register_argc_argv, and why would it be enabled by default?
It is a PHP setting that exposes command-line style arguments to PHP scripts, normally relevant for CLI usage rather than typical web requests. It ships enabled by default in the official PHP Docker image and in cPanel's default PHP configuration below version 8.5, which is precisely why this vulnerability reaches further than a more obscure, rarely enabled setting would.

Does disabling register_argc_argv fully protect an unpatched site?
It blocks this specific attack path, according to WordPress's own guidance, but it is explicitly described as a hardening measure, not a fix for the underlying bug. Update to 7.1.2 as the actual resolution.

How can I tell if attackers already successfully exploited my site?
Check access logs around and after September 23, 2026 for requests referencing page template paths or attempts to reach files like pearcmd.php, and look for unexpected files written to your webroot, since the observed attack pattern includes a write-to-disk stage in later-stage exploitation attempts.

Bottom line

This is a core WordPress vulnerability, not a plugin issue, which means every site is affected regardless of what you have installed. Update to 7.1.2 today if you have not already, check your logs for exploitation attempts given how fast and widespread the scanning activity has been, and if you run WordPress inside Docker or on a cPanel host with an older PHP version, treat this as directly relevant to your exact setup, not a generic advisory to skim past.

Sources: BleepingComputer, Hackers start exploiting critical WordPress flaw for code execution; CrowdSec, CVE-2026-87902 vulnerability tracking report; SecurityWeek, Critical WordPress Vulnerability Exploited Immediately After Disclosure. Verified against reported disclosure and exploitation details on October 4, 2026.