Attackers wasted little time exploiting a recent WordPress vulnerability in the wild.
Threat actors are actively targeting CVE-2026-87902, a critical WordPress Core vulnerability that can lead to remote code execution (RCE) under specific conditions. Researchers observed attempts to identify vulnerable websites less than five hours after WordPress released its fix on Sept. 22, with subsequent attacks progressing to attempts to write files that could execute shell commands.
The rapid escalation gives WordPress administrators a narrow window to act. Sites running vulnerable versions should update immediately and review for post-compromise activity.
WordPress flaw can lead to remote code execution
CVE-2026-87902 is an unauthenticated path traversal vulnerability in WordPress Core’s page-template resolution process.
According to the official WordPress advisory, an unauthenticated attacker can cause WordPress’s get_page_template() function to include a readable local PHP file located outside the active theme directories.
WordPress assigned the vulnerability a 9.2 CVSS v4.0 score and classified it as critical. No authentication or user interaction is required, although several environmental conditions must be met before the vulnerability can be exploited to achieve RCE.
Those conditions include:
- The active parent or child theme must contain a top-level directory beginning with page-, such as page-templates.
- A suitable local PHP file must exist and be readable by the web server.
- For the documented pearcmd.php route to RCE, PHP’s register_argc_argv setting must be enabled.
The WordPress advisory specifically identifies the legacy Twenty Twelve and Twenty Fourteen themes, as well as third-party themes such as Neve, Hestia, and Sydney, as examples that meet the theme-directory condition.
The vulnerability affects WordPress branches from version 4.7 through 7.1.1. WordPress fixed the current branch in version 7.1.2 and backported the security fix to older branches eligible to receive security fixes, dating back to WordPress 4.7. WordPress notes that only its most recent version is actively supported.
The WordPress 7.1.2 release recommends that administrators update immediately.
This is not the first serious WordPress Core vulnerability to surface this year. In July, public exploits emerged for a separate WordPress RCE attack chain that combined two vulnerabilities to achieve pre-authentication code execution.
Attacks escalated after initial probing
The speed at which attackers moved is particularly notable.
Patchstack researchers observed the first probing attempts at 17:44 UTC on Sept. 22, less than five hours after WordPress 7.1.2 was released.
Those initial requests appeared to be reconnaissance. Attackers attempted to include ordinary WordPress Core files, allowing them to determine whether a site was vulnerable without necessarily executing attacker-controlled code.
The activity soon escalated. By Sept. 23, malicious traffic associated with the vulnerability had reportedly increased roughly tenfold, and attackers were attempting to write files to vulnerable systems, according to BleepingComputer’s report.
Some observed files simply marked a host as exploitable. Others contained code designed to execute a shell command when the file was accessed, indicating that attackers had progressed beyond vulnerability reconnaissance toward attempts at code execution.
Singapore’s Cyber Security Agency issued another warning on Sept. 24. In an active exploitation alert, the agency said CVE-2026-87902 was reportedly being exploited and urged administrators to update affected WordPress installations immediately.
The activity follows several recent attacks against the broader WordPress ecosystem. Earlier in September, attackers launched more than 100,000 exploit attempts against a vulnerable WooCommerce plugin, exploiting the flaw to upload PHP web shells.
A separate vulnerability disclosed this month left millions of installations of the All-in-One WP Migration plugin running potentially vulnerable versions. CVE-2026-87902 is different because the vulnerability resides in WordPress Core itself rather than a third-party plugin.
What WordPress administrators should do now
The most important step is straightforward: install a patched WordPress release immediately.
WordPress 7.1.2 contains the fix for sites on the current branch. WordPress has also made security fixes available for affected older branches dating back to WordPress 4.7, although only the latest WordPress version is actively supported.
Administrators should also review web server and application logs for suspicious requests, particularly if their sites were exposed between the disclosure and the patch.
Patchstack recommends looking for unusual pagename parameters containing double-encoded traversal sequences, requests in which pagename and page_id appear together, and unexpected WordPress Core file output from normal page URLs.
Sites that were vulnerable during the exploitation window should also inspect their systems for unexpected or modified files, particularly PHP files that could indicate an attempt to execute code.
Must-read security coverage
- UK Police Convicts Pair in £5.5 Billion Bitcoin Launder Case
- Blackpoint Cyber vs. Arctic Wolf: Which MDR Solution is Right for You?
- How GitHub Is Securing the Software Supply Chain
- 8 Best Enterprise Password Managers
Why this matters for WordPress defenders
CVE-2026-87902 illustrates how quickly the window between disclosure and exploitation can collapse.
Attackers were probing for vulnerable installations less than five hours after the patch became public. By the following day, researchers were seeing attempts to write files that could execute shell commands, and by Sept. 24, Singapore’s cybersecurity agency warned that the vulnerability was being actively exploited.
The time to exploit window could become even tighter as AI accelerates vulnerability analysis and exploit development, although there is no indication AI was used in this attack.
For security teams managing WordPress environments, simply checking the version number is no longer enough. Administrators should confirm that patches have been applied to every internet-facing instance, inspect logs from before patching, and investigate any unexpected PHP files or other indicators of attempted exploitation.
The larger lesson is that a released patch no longer marks the end of a vulnerability story. For defenders, it can mark the beginning of the race.
Related reading: For more on the risks of delayed WordPress patching, read how hackers exploited newly patched WordPress flaws in an earlier attack chain that could lead to full site compromise.