WordPress CVE-2026-87902 probing began hours after fix

Attackers began probing WordPress sites for a critical vulnerability known as CVE-2026-87902 less than five hours after the patched release was published, according to a new report from Patchstack. The flaw is an unauthenticated local file inclusion issue in how WordPress resolves page templates, and it affects WordPress core versions from 4.7.0 through 7.1.1. A local file inclusion vulnerability lets a remote attacker make a website read a file it should not, which in this case can lead to remote code execution under some conditions. WordPress fixed the issue in version 7.1.2, with backported patches for older branches including 7.0.6, 6.9.9, 6.8.10 and as far back as 4.7.37. The vulnerability scores 9.2 on the CVSS scale, is unauthenticated, and Patchstack lists its exploitation status as active probing observed.

The vulnerability sits in the way WordPress builds a page template candidate from a URL parameter called pagename. Patchstack's Security Research Lead Dave Jong explains that the core issue is a path traversal leading to local file inclusion. In ordinary traffic, a URL like /?page_id=1&pagename=about tells WordPress which page to show. An attacker can instead use a specially crafted pagename value that starts with templates%252f followed by encoded dot-dot-slash sequences. The double encoding matters: WordPress first runs the slug through a sanitizer that strips literal dots and cuts at literal slashes, but it preserves percent-encoded octets. Later, get_page_template() decodes those octets and the traversal climbs out of the theme directory to include an arbitrary file. The attacker must also supply a valid page_id that resolves to a real page, because otherwise WordPress returns a 404 before the vulnerable code path is reached.

Patchstack says the first probing attempt reached its logs at 17:44 UTC on 22 September 2026, less than five hours after WordPress 7.1.2 was released. The payloads match the exact encoding the patch addresses, which suggests whoever built them was working from the diff rather than an independent discovery. So far, every observed request points the inclusion at an ordinary WordPress core file: wp-links-opml.php, wp-includes/functions.php or wp-cron.php. None of those files give an attacker anything on their own, but they work as a cheap yes-or-no test. For example, wp-links-opml.php emits a distinctive OPML document, so seeing that output from a normal page URL confirms the inclusion succeeded. Patchstack describes this as reconnaissance, not payload delivery: someone is building a list of exploitable hosts. The more dangerous step, pointing the same trick at a file like pearcmd.php on a server with register_argc_argv enabled, has not appeared in Patchstack's data yet, but the company expects it to follow once scanning results come back.

The observed requests share two telling details. First, they are double encoded at the HTTP layer, which is why %252e%252e appears in logs instead of a plain ../ sequence. Patchstack says this makes %252e%252e a low-noise string to search for. Second, every request pairs pagename with page_id, because the traversal alone is not enough to reach the vulnerable code. The pagename value begins with templates%252f, continuing a real directory that starts with page- before climbing out of the theme. Patchstack has seen traversal depth range from three to seven levels, likely to cope with different install layouts, and both uppercase and lowercase hex encodings. Requests arrive through GET and POST, because WordPress reads pagename from the POST body in preference to the query string. They also go to /index.php directly as well as the site root. The activity came from a small cluster of source addresses hitting multiple protected sites, with most volume concentrated in two neighbouring IPv4 addresses, 169.58.48.193 and 169.58.48.195, and some IPv6 traffic from 2001:df1:e8c0::106b. Most requests carried a Go-http-client/1.1 user agent, with a smaller share using spoofed browser strings. Activity peaked in the first hour and tapered off after that, which Patchstack says is the usual shape for an opportunistic sweep through a prepared host list rather than a targeted campaign.

Patchstack says its customers are protected by a RapidMitigate rule, a security rule that automatically blocks known attack patterns for protected sites, but for everyone else the fix is to update to WordPress 7.1.2 or the patched release on your branch. WordPress backported the fix as far as 4.7.37, so every affected branch has a patched release and an older site can take it without a major version jump. Site owners can check two preconditions from the original write-up before updating: whether the active theme has a top-level page- directory, and whether PHP has register_argc_argv enabled. If updating immediately is not possible, rejecting traversal sequences in the pagename parameter is an effective stopgap because a real page slug never contains one. For hunting through existing logs, Patchstack lists the highest-signal indicators: a pagename parameter containing %252e%252e in the query string or POST body, a pagename value beginning with templates%252f or another page- directory name, pagename and page_id appearing together on the site root or /index.php, and OPML output or any other unexpected core file output returned from a normal page URL. The last one tells you whether a probe succeeded: a 200 response carrying OPML where a page should have been means the inclusion worked on that host, and the site should treat it as a confirmed vulnerable window rather than a blocked attempt. Sites exposed before patching or mitigation should review historical logs on that basis and check for unexpected or modified files.

Patchstack's timeline shows WordPress 7.1.2 and the advisory GHSA-7hp8-65ch-5whp were published on 22 September 2026. The vulnerability was added to the Patchstack database and a RapidMitigate rule was deployed to protected sites the same day. The first exploitation attempt was observed and blocked at 17:44 UTC, and the most recent activity at the time of writing was 19:51 UTC. Patchstack is continuing to monitor for a shift from core file probes to inclusion targets that actually do something, and says it will update if that changes. For website owners on managed WordPress hosting such as AEU Hosting, core updates and server-level security monitoring can shorten the window between a patch release and its application, which is exactly what reduces exposure to fast-moving probes like this one.