If you run WordPress — whether it’s one blog or a fleet of client sites — stop what you’re doing and check your version. A critical flaw in WordPress core, tracked as CVE-2026-87902 (CVSS 9.2), is under active exploitation in the wild, and attackers started hammering sites within hours of disclosure. This is a remote code execution bug in WordPress itself, not a plugin. If the preconditions are met, an unauthenticated attacker can drop a web shell on your server and take the whole thing over.

What the vulnerability is

CVE-2026-87902 lives in how WordPress resolves page templates. An unauthenticated attacker can manipulate the get_page_template() page-template resolution so it includes a readable local .php file that lives outside the active theme’s directories. When the right conditions on both the server and the active theme are in place, that file inclusion turns into full remote code execution — no login required, no elevated privileges, nothing.

The two preconditions you need to worry about:

• The active child or parent theme contains a top-level directory whose name starts with page- (for example, page-templates).
• A chosen local .php target file exists on the server and is readable by the web server account (for example, pearcmd.php on many PHP installs).

Both are common. A huge share of commercial and custom themes ship a page-templates folder, and pearcmd.php ships by default with many PHP installations. That’s why this one is dangerous: the two conditions are independently common, and when they line up, the door is wide open.

How the attacks are playing out

WordPress shipped a fix on September 22, 2026, and the first exploitation attempt was recorded at 11:49 a.m. UTC the same day. This was not a slow burn — attackers operationalized the bug within hours. Telemetry from threat researchers logged 68 exploitation attempts starting September 23, plus reconnaissance and active probing across the attack surface.

The real-world payloads are nasty. Researchers have observed attackers:

• Including /usr/local/lib/php/pearcmd.php to write attacker-controlled PHP files to /tmp and /var/tmp.
• Dropping PHP files with names like wp-pear-rce-flag.php, poc87902.php, and randomized luci_<random>.php / zeta_<random>.php files.
• Fetching a PHP upload script from a public GitHub repository to stage a full web shell on the compromised server.

The exploitation goes in stages: first recon against harmless core files, then active exploitation that writes files to disk. Attack traffic has been seen from IPs in the U.S., Indonesia, and elsewhere — this is not a single targeted group, it’s broad opportunistic exploitation, and it’s the kind that screams for automation.

Why it matters for you

WordPress runs roughly 43% of the web. A core-level, unauthenticated RCE is about as serious as it gets — the vulnerability is baked into WordPress itself, so it affects millions of sites regardless of theme or plugin mix. And because WordPress enables automatic background updates by default, a large share of sites may self-patch. But “may” is not “will”: auto-updates are siloed to minor security releases, custom configuration can disable them, and many managed hosts or hardened installs turn the feature off. If auto-update is disabled, backdoored, or out of sync, you are exposed.

Unlike the plugin bugs we’ve covered before, this one is squarely in core. It doesn’t matter how carefully you vet your plugins if the engine underneath has a hole an unauthenticated attacker can drive a truck through.

What you should do right now

1. Update WordPress — today. The fixed releases are 7.1.2, 7.0.6, 6.9.9, and 6.8.10 (depending on your branch). If you’re on an older version, update to the nearest patched release. This is the single most important step — nothing else matters until the hole is closed.

2. Check that updates actually applied. Log into the dashboard and confirm your version matches a patched release. Don’t assume auto-update did the job. Many WordPress compromises in this type of incident are the ones where the site owner assumed updates were running.

3. Hunt for signs of compromise before and after patching. Look in /tmp and /var/tmp for unexpected .php files, scan for the observed filenames (poc87902.php, wp-pear-rce-flag.php), and audit web server logs for requests referencing pearcmd.php or page template paths. If you find anything, assume full compromise: reset all credentials, rotate API keys, check for a web shell, and review users and cron jobs.

4. Harden your PHP environment while you’re at it. Disable pearcmd.php if you don’t need it, and review which local .php files are world-readable by the web server account. Even after you patch, reducing the pool of useful include targets raises the bar for the next variant.

5. Turn auto-updates on for core if they’re off. If you disabled automatic updates for some reason, re-enable them for core security releases. The attackers are fast — the first hit came the same day as the patch. Your best defense against a flaw like this is patching faster than they can weaponize it.

WordPress core RCE with active, confirmed in-the-wild exploitation is not a tomorrow problem. Patch today, check your servers for web shells, and don’t assume the update ran. That’s the difference between being a headline and reading one.