Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure

Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure

Threat actors began actively exploiting a critical WordPress core vulnerability within hours of its public disclosure, according to reporting from The Hacker News. The flaw, tracked as CVE-2026-87902, carries a CVSS score of 9.2 and allows an unauthenticated attacker to achieve remote code execution (RCE) on affected sites under certain conditions. WordPress shipped a fix in version 7.1.2 on September 22, 2026, and security firm Patchstack reported observing exploitation attempts the same day the patch went live — a gap of only a few hours between disclosure and active attacks.

Details

How It Works

Root Cause

CVE-2026-87902 lives in WordPress core's page-template resolution logic, not in a third-party plugin or theme. When WordPress resolves which template file to render for a page request, it builds a candidate filename from the pagename query parameter in the form page-{pagename}.php. A neighboring code path in the same file applies validate_file() to block directory traversal, but the pagename branch does not. WordPress's URL sanitizer strips literal dots from the parameter but leaves percent-encoded dots intact; an attacker who sends double-encoded traversal sequences can survive that sanitization step, and get_page_template() subsequently calls urldecode(), which finishes decoding the payload into a working ../../ traversal sequence. The result lets an unauthenticated attacker force WordPress to include a chosen, readable local .php file located outside the active theme directory.

From File Inclusion to Code Execution

By itself, the bug is a local file inclusion (LFI) issue. Escalating it to full RCE requires three additional conditions to line up:

1. The active parent or child theme contains a top-level directory whose name starts with page- (for example, page-templates)
2. A local .php file the attacker wants to target exists on the server and is readable by the web server account
3. PHP's register_argc_argv setting is active, which is required for the specific exploitation chain researchers demonstrated

Security researcher Robert Ressl, who reported the flaw to the WordPress security team, published a proof-of-concept and a reproducible lab environment on GitHub after the patch shipped. His demonstrated chain targets pearcmd.php — the command-line utility bundled with PHP's PEAR package manager — at common install paths such as /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php, and /usr/share/pear/pearcmd.php. Because PEAR's command tool accepts arguments via the query string when register_argc_argv is on, an attacker can invoke its config-create functionality to write an attacker-controlled PHP file to disk — commonly dropped into /tmp or /var/tmp — and then request that file directly to execute arbitrary shell commands. WordPress's advisory notes that the official PHP Docker image and default cPanel configurations running PHP versions before 8.5 are both susceptible to this specific chain, which broadens the practical attack surface considerably beyond a narrow theme-naming edge case.

Active Exploitation Timeline

Patchstack, which monitors traffic across its customer base, reported that the first exploitation attempts arrived within hours of the patch's release — well before most self-hosted sites had a realistic chance to update. Observed activity progressed through recognizable stages: initial reconnaissance requests probing ordinary WordPress core files to fingerprint vulnerable installs, followed by capability checks against pearcmd.php to confirm PEAR was present and reachable, and finally attempts to write malicious PHP files to disk for execution. Patchstack characterized the escalation as a roughly tenfold increase in related traffic as attackers moved from probing to payload delivery over the following day. Because Ressl's PoC is public, the barrier to reproducing the attack chain is low — though the theme-directory and file-readability prerequisites mean not every WordPress install is automatically exploitable for full code execution, even if every install prior to 7.1.2 is technically vulnerable to the underlying traversal bug.

Impact Assessment

Recommendations

For Site Administrators

• Update to WordPress 7.1.2 immediately. WordPress backported the fix to all security-supported branches; sites unable to move to 7.1.2 directly should apply the corresponding patched release for their branch. Sites with automatic background updates enabled should already be receiving the fix.
• Audit for indicators of compromise, including unexpected .php files in /tmp, /var/tmp, or web-accessible directories, with names such as those referencing "pear," "rce," or "poc" strings, and any unfamiliar PEAR-related requests in access logs.
• Check whether your active theme has a top-level directory starting with page- and review server logs for pagename requests containing encoded traversal sequences (%2e%2e, double-encoded dots) alongside page_id parameters.
• Confirm PHP's register_argc_argv setting and disable it if not explicitly required — this removes a key link in the demonstrated exploitation chain.

For Security Teams

• Deploy or update WAF rules to reject requests where the pagename parameter contains traversal sequences, and monitor for requests targeting pearcmd.php at known install paths.
• Treat any pre-7.1.2 WordPress instance as vulnerable to the underlying LFI regardless of theme structure, and prioritize patching internet-facing installs first given confirmed active scanning.
• Review hosting environments built on the official PHP Docker image or cPanel with PHP versions before 8.5, which the WordPress advisory specifically calls out as exposed to the documented exploitation chain.

For Website Users

• If you manage or administer a WordPress site, do not delay patching — exploitation began within hours of disclosure, well ahead of typical patch-adoption timelines.
• If you run a WordPress site through a managed host, confirm with your provider that core updates are applied automatically or request manual confirmation that 7.1.2 (or the appropriate backported release) is installed.

Key Takeaways

1. CVE-2026-87902 is a critical (CVSS 9.2) unauthenticated path-traversal flaw in WordPress core's get_page_template() function, affecting versions 4.7.0 through 7.1.1.
2. WordPress patched the issue in version 7.1.2, released September 22, 2026, with fixes backported to all security-supported branches.
3. Active exploitation began within hours of the patch's release, according to Patchstack — one of the fastest observed gaps between disclosure and in-the-wild attacks against a WordPress core flaw.
4. Full remote code execution requires specific conditions: a theme directory starting with page-, a readable target .php file, and PHP's register_argc_argv setting enabled — commonly satisfied via pearcmd.php.
5. A public proof-of-concept from researcher Robert Ressl has lowered the barrier to exploitation, and attackers have already progressed from reconnaissance to writing malicious PHP files to disk.
6. Site administrators should patch to 7.1.2 immediately, audit for the indicators described above, and not assume the theme/file prerequisites provide meaningful protection against the base vulnerability.

Sources

• Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure — The Hacker News