CVE-2026-87902 (CVSS 9.2): WordPress Core Zero-Day Exploited Within Hours — Hundreds of Millions of Sites Face Unauthenticated RCE

On the morning of 22 September 2026, WordPress shipped routine security releases and, within the same hour, attackers began probing millions of servers worldwide. By the following morning, active exploitation of CVE-2026-87902 — a CVSS 9.2 critical unauthenticated remote code execution (RCE) flaw in WordPress Core — was confirmed across dozens of IP addresses. If your site runs WordPress 7.1.1 or earlier and has not yet been patched, it is potentially accessible to any unauthenticated attacker with a few lines of Python. This is not a plugin vulnerability. This is WordPress Core itself, the engine powering an estimated 43 percent of all websites on the internet — including a vast number of enterprise intranets, e-commerce portals, government portals, and media properties across India and the rest of the world.

What Is CVE-2026-87902? The 30-Second Brief

CVE-2026-87902 is a flaw in the way WordPress Core’s get_page_template() function resolves page templates. An unauthenticated attacker can craft a specially formed HTTP request that manipulates the pagename parameter, causing WordPress to include an arbitrary PHP file from outside the active theme directory rather than a legitimate theme template file. This class of attack is known as Local File Inclusion (LFI).

The vulnerability was discovered and responsibly disclosed by Austrian security researcher Robert Ressl, who published a detailed technical write-up. The security community’s response was swift — but so were the attackers. According to BleepingComputer, exploitation probes began within five hours of the patch announcement on September 22, and by September 23, Patchstack telemetry recorded payloads actively writing PHP webshells to compromised servers.

Technical Deep-Dive: The pearcmd.php Attack Chain

To understand why this vulnerability is so dangerous, you need to understand the specific attack chain that makes LFI escalate to full RCE. The chain has three links:

Link 1 — File Inclusion via Traversal

WordPress receives a request with a manipulated pagename value containing double-encoded traversal sequences (e.g., %252e%252e%252f) and a valid page_id. Instead of loading a theme template, WordPress resolves to a server-readable PHP file specified by the attacker.

Link 2 — Weaponising pearcmd.php

On many shared hosting environments, cPanel deployments, and official PHP Docker images running PHP versions below 8.5, the PHP PEAR package manager’s command-line tool — pearcmd.php — is installed and readable by the web-server process. When PHP’s register_argc_argv directive is enabled (often the default in these environments), PEAR can be invoked from a web request to download and install arbitrary PEAR packages — effectively executing attacker-controlled commands.

Link 3 — Writing a Persistent Webshell

Patchstack researchers confirmed attackers are targeting the pearcmd.php path to write PHP files with names like wp-pear-rce-flag.php, poc87902.php, and randomised variants to /tmp and /var/tmp. Once written, these files are directly accessible over HTTP and act as persistent backdoors, granting the attacker ongoing shell access even after the WordPress core is patched — unless the malicious files are also removed.

The confirmed attacker infrastructure as of publication includes the IP addresses 169.58.48.193, 169.58.48.195, and 2001:df1:e8c0::106b. Defenders should immediately check access logs for requests to these IPs and for URL paths containing pearcmd, wp-pear, or double-encoded traversal sequences.

Attribute	Detail
CVE ID	CVE-2026-87902
CVSS 4.0 Score	9.2 — Critical
Affected Versions	WordPress 4.7.0 – 7.1.1
Patched Versions	7.1.2, 7.0.6, 6.9.9, 6.8.10 + backports
Attack Vector	Network — no authentication required
RCE Prerequisites	Theme with page-* directory + readable PHP file (pearcmd.php) + register_argc_argv=On
Exploit in the Wild	Yes — confirmed, September 22 2026
CISA KEV	Monitoring — expected addition

Who Is Vulnerable?

Two prerequisites must align for RCE to be achievable, but the bar is lower than it might appear:

1. The active theme must contain a top-level directory starting with page- — for example page-templates/. This is a common naming convention used by dozens of popular commercial and free themes, including many WordPress theme marketplaces.
2. A readable PHP file must exist on the server outside the theme directory — specifically one like pearcmd.php, which ships by default on cPanel hosting environments, official PHP Docker images running PHP < 8.5, and many shared hosting stacks. These conditions exist on a substantial fraction of real-world WordPress deployments.

The LFI component (without the RCE escalation) affects virtually all unpatched WordPress installations, and even LFI alone can expose sensitive configuration files, PHP error logs, or cached authentication tokens.

For Indian enterprises, the risk is particularly acute: India has one of the largest WordPress deployment footprints in Asia-Pacific, with government digital initiatives (Digital India portals, state department websites), major media properties, fintech front-ends, and e-commerce platforms all running WordPress. Many of these run on shared cPanel hosting or containerised PHP environments where pearcmd.php is accessible by default.

Active Exploitation: What Attackers Are Doing Right Now

According to The Hacker News and Patchstack telemetry, exploitation evolved in two stages:

Stage 1 — Reconnaissance (September 22): Attackers sent probes against harmless core PHP files to fingerprint vulnerable installations, confirm file inclusion works, and identify the server stack. This stage is low-noise and may not trigger standard WAF rules.

Stage 2 — Payload Delivery (September 23 onwards): Attackers transitioned to full exploitation, using pearcmd.php to write PHP webshells to disk. File names observed include wp-pear-rce-flag.php and randomly suffixed variants. The webshells are placed in /tmp and /var/tmp, which are typically writable by the web-server process. Once written, these files execute shell commands on request via the web, giving attackers a persistent foothold even after patching.

As of publication, 68 exploitation attempts have been recorded by Previdian telemetry. Given that large-scale scanning infrastructure typically takes 24–72 hours to fully spin up after a public PoC appears, the volume of attacks is expected to increase sharply over the coming days.

What You Should Do Right Now — A Practitioner’s Checklist

Having spent three decades hardening networks for enterprises in Delhi NCR and across India, I cannot stress this enough: patch velocity is the single most important variable in whether a disclosed vulnerability becomes a breach. Here is the checklist every WordPress site owner and operations team should run through today.

1. Verify your WordPress version immediately. Log into your WordPress admin panel. Navigate to Dashboard → Updates. If you are running any version prior to 7.1.2 (or the equivalent backport for your branch), update now. For bulk managed environments, use WP-CLI: wp core update --version=7.1.2.
2. Confirm auto-updates succeeded. Auto-updates are enabled by default for minor releases, but they fail silently when file permissions are restrictive, when a caching plugin interferes, or when the WordPress admin email bounces. Check your version number — do not trust auto-update logs alone.
3. Search for webshell artefacts. Run the following check on your server (or ask your hosting provider to run it): search /tmp, /var/tmp, /wp-content/uploads, and your web root for PHP files created or modified after September 21, 2026. Specifically hunt for filenames containing pear, poc, or random-looking strings ending in .php.
4. Audit access logs for exploitation indicators. Search your access logs for requests containing pearcmd, double-encoded traversal patterns (%2525, %252e%252e), and requests from the known attacker IPs: 169.58.48.193, 169.58.48.195, 2001:df1:e8c0::106b.
5. Harden PHP configuration. Set register_argc_argv = Off in your php.ini. This breaks the pearcmd.php RCE chain. Also consider disabling PEAR components entirely: open_basedir restrictions and disable_functions settings can limit blast radius even if LFI is achieved.
6. Deploy a Web Application Firewall (WAF) rule. Wordfence, Sucuri, Cloudflare, and most enterprise WAF vendors have already published virtual patch rules for CVE-2026-87902. For FortiGate-protected perimeters with a FortiWeb or FortiGuard WAF subscription, ensure IPS signatures are current — Fortinet typically pushes CVE signatures within 24–48 hours of CISA KEV addition.
7. If exploitation is suspected, isolate and forensicate. Take the site offline, preserve a disk image, audit all PHP files and database tables for injected content, rotate all WordPress admin passwords and API keys, and notify affected parties per your data-breach response plan. Under India’s DPDP Act, if personal data was exposed, notification obligations may be triggered within 72 hours.

For organisations subject to SEBI’s CSCRF framework — including Qualified Registrars, Stock Brokers, Asset Management Companies, and Depositories — Internet-facing web applications are in scope for your periodic vulnerability assessment cycle. A confirmed exploitation of a CVSS 9.2 flaw in a production application triggers an immediate incident report to CERT-In.

The Broader Context: Why WordPress Vulnerabilities Hit Different

Most critical CVEs affect a single vendor’s product and a defined universe of customers. CVE-2026-87902 is different because WordPress is not a product — it is infrastructure. It underpins medical clinic booking portals, municipal corporation e-governance sites, school management platforms, and small business storefronts simultaneously. When a CVSS 9.2 flaw drops in WordPress Core, the downstream risk isn’t one enterprise’s servers: it is the combined surface area of every site running an outdated version.

This incident reinforces a core principle of the zero-trust security model: assume breach. Patching is necessary but insufficient. Defender posture should always include network segmentation (so a compromised web server cannot pivot to your database tier), least-privilege PHP execution, immutable infrastructure patterns where web roots are read-only at runtime, and continuous monitoring for anomalous file creation events.

For more on deploying layered perimeter defences that protect web-tier assets, see my guide to firewall policy auditing for Indian enterprises.

Frequently Asked Questions

Does CVE-2026-87902 affect every unpatched WordPress site?

The Local File Inclusion component is present in all unpatched WordPress 4.7.0–7.1.1 installations. However, escalation to Remote Code Execution requires the active theme to have a page-* directory and a readable PHP file like pearcmd.php accessible from the web server. These conditions are common on shared hosting, cPanel environments, and PHP Docker containers running PHP < 8.5 — so the RCE risk is real and broad, but not universal. Even without RCE, LFI can expose sensitive server files.

My hosting provider says they patched automatically. Am I safe?

Verify rather than trust. Log into your WordPress dashboard and confirm your version shows 7.1.2 (or the relevant backport). Also ask your host whether they have checked for active exploitation artefacts — a successful patch stops future attacks but does not evict webshells already written to disk by earlier attacks. If you were running 7.1.1 between September 22 and your patch timestamp, assume the window was open and run the forensic checks described above.

I disabled auto-updates on my staging site. What should I do?

Update immediately via the WordPress dashboard or WP-CLI. If your staging environment shares a server or network with production, treat it as a potential pivot point. Ensure the staging environment’s register_argc_argv is set to Off and that pearcmd.php is either absent or inaccessible. Also verify that credentials used on staging are not reused on production — attackers frequently use staging footholds to reach production databases.

Is there a way to check if I’m already compromised without hiring a forensics team?

Yes. Start with these quick checks: (1) Run find /var/www /tmp /var/tmp -name "*.php" -newer /etc/wordpress/wp-config.php -mtime -5 2>/dev/null to find recently created PHP files. (2) Grep your access logs for pearcmd and double-encoded URL patterns. (3) Review your WordPress Users list for unknown admin accounts added after September 21. If any of these return suspicious results, escalate to a professional incident response engagement immediately. I offer rapid-response security assessments for Indian enterprises — contact me today if you have concerns.

---

Sources: BleepingComputer · The Hacker News · SOC Prime · SOCRadar · NVD