WordPress Core Flaw CVE-2026-87902 Drew Exploit Attempts on Patch Day

WordPress fixed a flaw in its own core on 22 September 2026 that lets an unauthenticated visitor make a site load a PHP file of the attacker's choosing from outside the active theme. On some combinations of theme and server, that becomes remote code execution. Attackers did not wait long: Patchstack logged the first exploitation attempt at 11:49 UTC that same day, and the researcher who found the bug published a working proof of concept alongside the advisory. CISA added the flaw to its Known Exploited Vulnerabilities catalog on 25 September.

The bug is CVE-2026-87902, an improper control of filename for an include statement (CWE-98) in the get_page_template() function. It affects every WordPress release from 4.7.0 through 7.1.1. WordPress rates it 9.2 Critical under CVSS 4.0, with the vector flagging that attack requirements are present (AT:P). CISA's own scoring puts it at 8.1 High under CVSS 3.1, with high attack complexity. Both numbers say the same thing in different ways: anyone on the internet can send the request, but whether it ends in code execution depends on how the site is built and hosted.

This is not a plugin bug. It sits in WordPress core, so the question for site owners is not whether they run some obscure add-on but whether their theme and their PHP setup meet the conditions below.

---

Who is affected

Every branch from 4.7 onward received a fix: 25 releases in all, published on 22 September.

Sites that accept automatic background updates should already have the fix. Sites with background updates turned off, managed hosts that pin versions, and anything running a forked or vendored copy of core need a manual update.

Being on a vulnerable version is not enough for code execution. Three things have to line up.

1. The active theme has a top-level directory whose name starts with page-. WordPress's own theme documentation suggests page-templates/ as a place to keep custom page templates, so this is a normal layout. The advisory names the legacy Twenty Twelve and Twenty Fourteen themes and the popular third-party themes Neve, Hestia and Sydney as affected. The current default themes the researcher inspected, Twenty Twenty-Three through Twenty Twenty-Five, do not have such a directory.

2. A readable PHP file on the server does something useful when included. The well-known target is PEAR's pearcmd.php, which accepts command-line style arguments from the query string when PHP's register_argc_argv setting is On. The advisory says the official php Docker image is affected, and so is the default cPanel configuration when PHP older than 8.5 is in use.

3. Nothing confines PHP's file access, such as open_basedir, and the web server user can write somewhere, typically /tmp.

The PoC also needs a published page that anonymous visitors can reach, without a custom template already assigned to it. Most sites have one.

How the attack works

The researcher, Robert Ressl, reported the flaw through HackerOne on 20 July and published his write-up and lab on the day of the fix. His analysis describes four steps that fail one after another:

1. Sanitization runs too early. WordPress cleans the pagename query variable, but the cleaner rewrites literal dots and slashes and leaves percent-encoded octets alone. A double-encoded traversal sequence such as %252e%252e survives it.
2. Page lookup and template lookup disagree. The attacker selects a real page with page_id, so the request resolves, while the poisoned pagename stays in the query object for template resolution.
3. Decoding happens late. get_page_template() runs urldecode() on the slug and builds a candidate path with a fixed page- prefix and .php suffix. The encoded separators turn back into real ../ at this point.
4. No containment check. The loader checks that the resolved file exists, is readable and ends in .php, but never checks that it is still inside the theme directory.

The fixed page- prefix is why the theme precondition matters. The traversal has to start from a real directory whose name begins with page-, such as page-templates/, before it can climb out of the theme.

How a single unauthenticated request climbs out of the theme directory, and the three conditions it needs to end in code execution. Sources: Robert Ressl, WordPress advisory GHSA-7hp8-65ch-5whp.

From there, including pearcmd.php with register_argc_argv enabled lets the attacker pass PEAR commands in the URL. Its config-create command writes a file with attacker-controlled content to a writable path, and a second request includes that file. The code runs as the web server user.

Ressl's proof of concept is public at github.com/ressl/cve-2026-87902-poc. Its lab pins the wordpress:7.0.2-php8.3-apache Docker image, adds an empty page-templates/ directory to Twenty Twenty-Five, and turns register_argc_argv on. Several other repositories with toolkits and scanners built on it have since appeared on GitHub.

What attackers are doing

Patchstack, which runs a WordPress firewall, published a running account of the traffic it blocked:

• 22 September, 11:49 UTC. The first exploitation attempt, probing harmless core files such as wp-links-opml.php, wp-cron.php and install.php to confirm the traversal works.
• 22 September, 15:34 UTC. The first attempt to write a file to disk through pearcmd.php.
• 23 September. Public scanning tools circulated, and volume peaked around midday UTC.

By its update, Patchstack said traffic was running at more than ten times the volume of the first evening and had spread from a small cluster of addresses to a few hundred. Attackers checked three standard PEAR locations (/usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php and /usr/share/pear/pearcmd.php) and used config-create to write PHP files into /tmp and /var/tmp. Patchstack does not say whether any of those attempts succeeded on a real site.

CISA's KEV entry, titled "WordPress Core Remote File Inclusion Vulnerability", records exploitation as active and set a remediation deadline of 28 September for US federal civilian agencies. The entry is flagged for forensic triage under BOD 26-04, which means agencies are expected to look for compromise, not only to patch. Use in ransomware campaigns is listed as unknown.

---

What to do

Update core now. Move to the fixed release for your branch from the table above, and confirm the version in the dashboard or with wp core version rather than assuming the auto-updater ran.

If you cannot update today, these break the demonstrated route to code execution but do not fix the inclusion bug itself:

• Set register_argc_argv = Off in the PHP configuration used for web requests.
• Remove PEAR, or at least make pearcmd.php unreadable to the web server user, if nothing needs it.
• Set open_basedir and restrict where the PHP user can write.
• At the firewall or WAF, reject requests whose pagename parameter contains %2e%2e or %252e%252e, and requests that combine pagename with page_id on the site root or index.php.

Check whether you were targeted. Patchstack's indicators:

• pagename values containing %2e%2e or %252e%252e in access logs.
• Requests containing pearcmd, +config-show or +config-create.
• The user agents cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0.
• Unexpected .php files in /tmp or /var/tmp.

A site that matched all three preconditions and was unpatched after 22 September should be treated as potentially compromised: review recently written PHP files across the web root and temp directories, rotate database and admin credentials, and check for new administrator accounts.

Sources

• NVD: CVE-2026-87902
• WordPress security advisory GHSA-7hp8-65ch-5whp
• CISA Known Exploited Vulnerabilities catalog: CVE-2026-87902
• Patchstack: Attackers started probing WordPress sites hours after the patch
• Robert Ressl: CVE-2026-87902, critical WordPress file inclusion and conditional RCE
• Robert Ressl: CVE-2026-87902 proof of concept (GitHub)
• Help Net Security: WordPress 7.1.2 fixes critical unauthenticated path traversal vulnerability