WordPress Patched a Flaw Reaching Back to 2016. Scanners Found the Unpatched Sites in Under Five Hours

WordPress shipped 7.1.2 on 22 September and backported the same fix across every security branch it still supports, down to 4.7. The flaw, CVE-2026-87902, lets an unauthenticated visitor steer page template resolution into including a readable local PHP file from outside the active theme directories, and on some hosts that turns into remote code execution. Patchstack says it blocked the first exploitation attempt at 17:44 UTC the same day — under five hours after the release went out.

That gap is the story. The patch is also the disclosure, and for software that runs 40.2% of all websites, the window between the two is where the damage happens.

A flaw with a nine-year reach

The affected range starts at 4.7.0, which shipped in December 2016. WordPress does not routinely backport to branches that old; the fact that it did here is the clearest statement of how it reads the exposure.

W3Techs put WordPress at 40.2% of all websites and 58.8% of the CMS market on the day of the release, with version 7 on 62.5% of WordPress installs. The remaining third is the part worth worrying about.

The conditional part is doing a lot of work

Both the project and Patchstack are careful to say the code execution is conditional. The file inclusion works regardless; turning it into execution needs an active theme carrying a top-level directory like page-templates, which Patchstack notes is common in legacy default themes and popular third-party ones, and it needs PHP's register_argc_argv enabled — on by default in the official PHP Docker images and in cPanel environments running PHP below 8.5.

Those are not exotic conditions. They are defaults, and the severity scoring reflects the disagreement about how much that matters. The project's advisory carries a 9.2. The CNA record published to CVE.org gives 8.1 with an attack-complexity-high vector, and NVD analysis is still pending. The arithmetic difference is whether a widespread default counts as a hurdle for an attacker or as the ordinary state of the internet. For a site operator the question is academic: the inclusion primitive is unconditional, and an attacker who can read arbitrary local PHP files is already inside the part of the system where configuration secrets live.

Five hours

Patchstack's telemetry describes an opportunistic sweep rather than a targeted campaign. The traffic came from a small cluster of source addresses — two neighbouring IPv4 addresses plus some IPv6 — peaked inside the first hour and then fell away. The requests were not attempts at execution. They were reconnaissance, using ordinary WordPress core files as a detection oracle to find out which hosts were still vulnerable.

That pattern is what mass exploitation looks like in its first stage. Somebody reads the advisory, builds a detector, and sprays it at the internet to build a target list. Execution attempts, when they come, are aimed at the addresses that answered.

What defenders should do

Update. Sites with automatic background updates enabled already have the patch and have had it since the release; WordPress's own guidance is to update immediately, from the dashboard or by downloading the release. The exposure sits almost entirely in the places where background updates are off: managed hosts that pin versions for compatibility, staging and archived installations nobody owns any more, and sites on branches so old that their operators have stopped thinking of them as software.

If patching has to wait, Patchstack and Hadrian both describe interim web application firewall filtering and what to look for in access logs — encoded traversal sequences in query parameters, and earlier requests that returned file content they should not have. Their advisories carry the detection detail; follow those rather than improvising a rule.

The vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities catalog, and as of writing nobody has reported a confirmed compromise. That will not stay true if the unpatched tail is as long as W3Techs' version distribution suggests. WordPress's auto-update mechanism is the single most effective piece of security infrastructure on the open web, and this release is a good demonstration of it — for the roughly two-thirds of installations it actually reaches.

Sources: WordPress 7.1.2 Security Release · WordPress security advisory GHSA-7hp8-65ch-5whp · Patchstack: WordPress 7.1.2 Security Release · Patchstack: Attackers Started Probing WordPress Sites Hours After the Patch · The Hacker News: WordPress Issues Patch for Critical Flaw · Hadrian vulnerability alert: CVE-2026-87902 · W3Techs: Usage statistics of WordPress