WordPress CVE-2026-87902 attacks reach code execution
WordPress CVE-2026-87902, a critical flaw in WordPress Core, is now being actively exploited beyond simple probing, according to Patchstack. The vulnerability affects WordPress versions 4.7.0 through 7.1.1 and was fixed in WordPress 7.1.2, with patched releases also listed as 7.0.6, 6.9.9, 6.8.10 and backports as far as 4.7.37. Patchstack reports a CVSS score of 9.2, which places it in the critical range, and says exploitation requires no login.
The issue is a path traversal leading to local file inclusion and conditional remote code execution. Path traversal means an attacker tries to make a website open files outside the folder it was meant to use. Local file inclusion means the site is tricked into loading a file already present on the server. Remote code execution, often shortened to RCE, means an attacker can make the server run their commands or code. In this case, Patchstack says the flaw sits in WordPress page template resolution, and the first exploitation attempt it observed arrived at 11:49 UTC on 22 September 2026, the same day WordPress 7.1.2 was published.
Patchstack says the campaign changed quickly. At first, the requests were reconnaissance against harmless WordPress core files, meaning attackers were checking whether sites were vulnerable. By 23 September, the traffic volume had grown to more than ten times the first evening’s level, had reached a wider spread of sites, and had moved through three stages: checking whether inclusion worked, checking whether PEAR’s pearcmd.php was reachable, and then attempting to write files to disk.
The first stage pointed the vulnerable template inclusion at ordinary core files. Patchstack says wp-links-opml.php remained the most common target, with wp-includes/feed-rss2.php also appearing in volume, along with wp-cron.php, wp-includes/functions.php, wp-login.php and install.php. A successful response from one of these files tells an attacker that the vulnerable code path is reachable.
The second stage targeted PEAR’s pearcmd.php. PEAR is a PHP package system, and pearcmd.php is a command script associated with it. Patchstack says attackers used requests containing a valid page_id, a pagename value with traversal encoding, and +config-show in the query string. When PHP runs with register_argc_argv enabled, the query string can be exposed to the included script as command-line style arguments, so +config-show is passed to pearcmd. That confirms both that PEAR exists on the host and that the argument trick works. Patchstack says attackers tried three locations: /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php and /usr/share/pear/pearcmd.php.
The third stage replaced config-show with config-create. Patchstack says pearcmd can use that to write a file where instructed, with attacker-controlled content. The observed requests tried to write PHP files, which turns the issue into code execution when the chain succeeds. Patchstack describes two broad groups of payloads: some write marker strings such as CVE-2026-87902-POC-OK or an obfuscated LUCIFER-RCE-OK built from chr() calls, behaviour consistent with building lists of vulnerable hosts; others write a short PHP tag that runs a shell command when accessed. Patchstack states that the second group is not research.
The files seen by Patchstack were dropped into /tmp and /var/tmp. Filenames included wp-pear-rce-flag.php, poc87902.php, luci_.php and zeta_.php. A PHP file in /tmp is usually not directly reachable over the web, so Patchstack describes that as proof of execution rather than a persistent backdoor by itself. Even so, the same ability to write a file can be used in more useful locations, and a host where this succeeds should be treated as compromised.
Patchstack also says the exploitation has been commoditised. It observed user agents cve-2026-87902-poc/1.0 and nuclei-cve-2026-87902/1.0, including a named Nuclei template. Nuclei is a scanning tool used to test many targets with templates. Patchstack says this means the activity is no longer limited to a few operators working from the patch diff. It also warns that most remaining traffic uses spoofed browser user agents, so filtering only by user agent is not reliable.
The early requests reveal why this is not a generic scan. Patchstack says the payloads match the encoding addressed by the patch, indicating that the first operators were working from the code difference rather than an independent discovery. WordPress sanitisation preserved escaped octets while rewriting literal dots and cutting at literal slashes, so a plain traversal string would not survive, but encoded traversal could. That makes %2e%2e and %252e%252e useful log indicators. The requests also usually included page_id alongside pagename. Patchstack says a real page ID is needed because otherwise WordPress returns a 404 and the page template path is not reached.
The campaign is not limited to one exact request pattern. Patchstack observed traversal depths from one to twelve levels, uppercase and lowercase encoded characters, single and double encoding, GET and POST requests, and traffic sent to both the site root and /index.php. POST later became more common than GET, and that matters because WordPress reads pagename from the POST body before the query string. Many payloads began with templates%2f because the traversal needs to continue a real directory starting with page- before climbing out of the theme. Patchstack also saw template and a malformed page-templates prefix.
Source IP blocking is unlikely to be enough. Patchstack says the first evening came from a small cluster of addresses, but the traffic later spread across a few hundred. The heaviest talkers it listed were 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170 and 92.246.130.76. It says file-write attempts came from a smaller subset, a pattern it describes as a few operators acting on results produced by a larger scanning population.
The practical priority is patching. Patchstack says WordPress 7.1.2, or the patched release for the relevant branch, remains the fix, and the existence of stage-three file-write attempts makes updating urgent. Because the fix was backported as far as 4.7.37, affected sites can receive a patched release without making a major version jump. Patchstack says site owners assessing exposure should consider whether the active theme has a top-level page- directory and whether PHP has register_argc_argv enabled.
If an immediate update is not possible, Patchstack says rejecting traversal sequences in the pagename parameter is an effective temporary measure, because a normal page slug does not contain them. Disabling register_argc_argv does not fix the file inclusion itself, but it breaks the pearcmd chain, which Patchstack says can be the difference between an information leak and code execution.