WordPress RCE Vulnerability Exploited Within Hours of the Patch

WordPress pushed out version 7.1.2 on 22 September to fix a critical flaw in its own core code. Attackers had working exploit attempts running against live sites within hours. The WordPress RCE vulnerability, tracked as CVE-2026-87902, carries a CVSS score of 9.2. It needs no login to trigger. If your site runs WordPress, this is not one to leave in the update queue.

What causes the WordPress RCE vulnerability

The bug sits in get_page_template(). WordPress uses this function to work out which template file should render a page. Security researcher Robert Ressl found that two request parameters, pagename and page_id, can be combined in a specific way. Percent-encoded traversal sequences survive WordPress’s initial checks and only get decoded later. By that point, the code has already picked a real, published page to authorise the request against, while the traversal payload just keeps travelling underneath it.

The end result: WordPress can be tricked into pulling in a PHP file from well outside the active theme’s own folders. That only needs two conditions: the file exists on the server, and the web server account can read it. Ressl put the underlying design flaw plainly. Resolving a path with a function like realpath() tells you where a file physically sits. It does not tell you whether that file belongs somewhere your application meant to trust.

From file inclusion to code execution

Path traversal alone lets an attacker read files they shouldn’t. Turning it into a full WordPress RCE vulnerability needs a bit more. Ressl’s write-up shows one route that works. It requires the active theme to have a top-level folder starting with page-, such as page-templates. That naming is a legitimate WordPress convention, not a bug in itself. It also needs PHP’s register_argc_argv setting switched on.

Given those conditions, an attacker can first include PEAR’s pearcmd.php file. They abuse its configuration-writing feature to drop a new PHP file onto disk. Then they include that file through the same flaw to run their own code. Security firm Patchstack monitors WordPress traffic across a large number of sites, and says that is exactly what it is now seeing in the wild.

A properly run disclosure, undone by speed

Ressl reported the flaw through WordPress’s HackerOne bug bounty programme on 20 July 2026. WordPress acknowledged receipt the following day. On 15 September, it told him a fix was planned. The advisory and the patch landed together on 22 September. That two-month window is fairly typical for a bug of this severity. It gave the WordPress security team time to prepare backports across dozens of older branches, rather than rushing out a single release.

None of that careful process bought site owners much breathing room once the patch went public. A responsible disclosure timeline protects against the bug leaking before a fix exists. It does not slow attackers down once the fix is out. The diff that reveals what changed is sitting in public view for anyone to read.

Attackers moved fast

Patchstack recorded the first probing request at 11:49 UTC on 22 September, the same day the patch shipped. Whoever sent it had already reverse-engineered the fix. By the next day, traffic aimed at the flaw was running at more than ten times the volume seen on that first evening.

The pattern Patchstack describes has three stages. Early requests hit ordinary WordPress files such as wp-links-opml.php, just to check whether a target is worth pursuing. Next come probes for pearcmd.php in its usual install locations. Once that succeeds, attackers use a config-create command to write files into /tmp or /var/tmp. Some are just marker files, flagging a vulnerable host. Others are short scripts built to run shell commands on demand. None of this works with a plain ../../ traversal string. Patchstack notes the payload only survives WordPress’s filtering once the separators are percent-encoded.

Who actually needs to worry about the WordPress RCE vulnerability

Every WordPress installation from version 4.7.0 up to 7.1.1 contains the flawed code. The WordPress security team has backported fixes across 24 branches going back that far, a strong signal of how seriously it takes this one. Only the current release line gets full ongoing support, so anything older than 4.7 is on its own.

Not every one of those sites can be turned into a full WordPress RCE vulnerability. That needs the specific theme folder structure and server configuration described above. But the path traversal and file disclosure on its own is a serious problem regardless. Ressl was careful to say the CVSS score reflects the severity when conditions are met. It is not a measure of how common those conditions are across the WordPress install base.

It is also not the only unauthenticated core flaw WordPress has fixed this year. A cross-site scripting bug patched in version 7.0.3 followed a similar pattern: no login needed to trigger it at all.

What to do now

Update to WordPress 7.1.2, or the appropriate patched point release for an older branch. Do not wait for a scheduled maintenance window. Sites with automatic background updates enabled should already be covered, but it is worth checking rather than assuming. If an immediate update genuinely is not possible, Patchstack suggests two stop-gaps. Block requests where the pagename parameter contains traversal sequences. Or turn off register_argc_argv in your PHP configuration, which breaks the chain that leads to code execution.

Either way, treat those as a holding position, not a fix. A WordPress RCE vulnerability being exploited within hours of disclosure is exactly the scenario patch management processes exist for. This is a clear case where speed matters more than process.

It is also a useful contrast with the more usual pattern, where a fix sits unused for months before anyone bothers to exploit it. Take a critical WooCommerce flaw patched back in February that attackers only started exploiting in September. Here, the delay was measured in hours, not months. That argues for treating every critical core advisory as urgent by default, rather than triaging by how old the bug looks.