CVE-2026-87902: WordPress Core LFI Flaw Exploited Within Hours of Patch

WordPress patched a critical unauthenticated file-inclusion vulnerability on September 22, 2026, and attackers were already probing sites before most administrators had finished their morning coffee. CVE-2026-87902 carries a CVSS 4.0 score of 9.2 and affects every WordPress release from 4.7.0 through 7.1.1 — a window that covers most of the internet given that WordPress now powers over 43% of all websites. The fix landed in WordPress 7.1.2, with backported patches released simultaneously for all branches still receiving security support, back to 4.7.

What the Flaw Actually Does

The vulnerability lives in get_page_template(), WordPress's function in /wp-includes/template.php that resolves which theme template should render a given page. WordPress builds a list of candidate template filenames, and one of those candidates is derived directly from the pagename value in the request URL — without adequate validation. An unauthenticated attacker can craft a URL that causes WordPress to include an arbitrary local PHP file readable by the web server, from anywhere on the filesystem, not just inside the active theme directory.

The flaw is classified as CWE-98 (Improper Control of Filename for Include/Require Statement in PHP Program). On its own, the ability to force an include of an arbitrary readable PHP file is serious — it enables reading configuration files, leaking credentials, and in certain server setups, full remote code execution.

The RCE Path: Conditional, But Not Rare

WordPress and security researchers have been careful to call this "conditional RCE" rather than universal code execution, and that distinction matters. For an attacker to actually run shell commands, three conditions must align:

• The active parent or child theme must contain a top-level directory whose name begins with page- (for example, page-templates, a directory structure used by many commercial themes).
• A suitable PHP file that the web server can read must exist on the server's filesystem. The most-exploited example is PEAR's pearcmd.php.
• PHP's register_argc_argv directive must be enabled, which allows pearcmd.php to accept command-line arguments via the query string.

That third condition sounds like a niche edge case, but it is the default in the official PHP Docker images and was the default in cPanel environments running PHP older than 8.5. Anyone running WordPress in a containerized environment — or on a cPanel stack that hasn't been tuned — should assume register_argc_argv is on until they confirm otherwise.

The observed attack chain: an attacker passes a crafted URL that includes pearcmd.php, passes a command to it via query-string arguments (exploiting register_argc_argv), and instructs PEAR to write a PHP webshell to a world-writable directory like /tmp or /var/tmp. The attacker then makes a second request to that webshell and has interactive code execution.

Active Exploitation: Within Five Hours

Patchstack and Bleeping Computer both confirmed that automated probing began within five hours of the 7.1.2 release. The initial wave was reconnaissance — scanning for the presence of page- subdirectories in active themes and checking for pearcmd.php — but exploitation attempts writing PHP files to disk were logged within the same day. Scan tooling for this CVE is already circulating in public repositories, meaning the barrier to running these attacks is essentially zero.

The Singapore Cyber Security Agency (CSA) issued a formal advisory on September 23. CISA has not yet added it to the KEV catalog as of this writing, but that listing tends to lag real-world exploitation by a few days.

What to Do Right Now

The patch is straightforward, but here is the complete action list in priority order:

• Update to WordPress 7.1.2 immediately. If automatic core updates are disabled for your site, override that setting for this release. Sites still on older branches (5.x, 6.x) should apply the backported security release for their respective branch.
• Check register_argc_argv. In your php.ini or cPanel PHP configuration, confirm register_argc_argv = Off. On sites where the full RCE path does not apply, this setting still has no business being on for a web-facing PHP process.
• Audit your active theme's directory structure. If your theme contains a subdirectory starting with page-, the full attack surface is open on unpatched sites. This is a good secondary reason to patch before doing anything else.
• Check for indicators of compromise. Review your access logs for requests containing path-traversal strings targeting template parameters. Look for unexpected new PHP files under /tmp, /var/tmp, or your WordPress upload directory. A recently created webshell will often have a name that blends in with WordPress core filenames.
• Verify PEAR is not installed where it does not need to be. If PEAR's pearcmd.php exists on your server, confirm whether it's actually in use. On most shared hosting stacks it's a legacy artifact; removing or restricting read access to it closes the primary RCE vector even on unpatched sites.

Context: The Fifth Core Security Release Since July

This is WordPress 7.1.2 — the fifth security release to the 7.1 branch since July. The cadence reflects both a maturing security program at Automattic and the reality that any platform running on a hundred million websites draws serious, continuous research attention. For site owners managing WordPress at scale, this release cycle is an argument for treating automatic core updates as non-negotiable. The window between patch and active exploit is now measured in hours, not weeks.

At Falcon Internet, the sites we manage updated automatically by the time the first scan traffic hit. The lesson from watching this space since 2000: the update cadence isn't the problem — the lag is.