You updated WordPress last week. Good. Now update it again.
WordPress 7.1.1 arrived on September 17 with maintenance work and 11 security fixes. Five days later, on September 22, WordPress released 7.1.2 as a security-only update with one critical fix. That timing feels ridiculous when you run a shop, booking site, or company website and had only just finished checking the previous update.
Still, this one shouldn’t sit until next week. Patchstack saw active probes at 17:44 UTC on release day, less than five hours after the patch became public. The first requests were reconnaissance, not proof that sites had been compromised. But the same-day scanning window is the danger.
What CVE-2026-87902 actually does
CVE-2026-87902 has a CVSS 4.0 score of 9.2 and affects WordPress 4.7.0 through 7.1.1. WordPress 4.7 was released on December 6, 2016, which means the vulnerable code path survived for almost ten years before public disclosure and a fix.
The flaw is an unauthenticated path traversal and local PHP file inclusion issue in page-template resolution. Unauthenticated means the person sending the request doesn’t need a WordPress account. Path traversal means a specially encoded request can try to step outside the location WordPress expected and point its template loader at another local file.
There is an important condition. For the practical local file inclusion route, the active theme needs a top-level directory whose name begins with page-. A common example is page-templates. Sites without that theme structure don’t match the documented route, even if their WordPress version falls inside the affected range.
And local file inclusion does not automatically mean full attacker-controlled code execution. The attacker still needs a useful, readable PHP file already present on the server. The documented route uses PEAR’s pearcmd.php and also depends on PHP having register_argc_argv enabled. Whether that combination is present depends on the server. So no, every affected WordPress installation was not automatically one request away from full RCE.
The probes appeared on patch day
The observed requests targeted ordinary WordPress core PHP files. They were being used as an oracle – a way to tell whether the path traversal behaved differently on a vulnerable host. This was scanning and host identification, not a confirmed payload drop, successful file inclusion, or proven remote code execution.
Patchstack confirmed that the probes used the exact encoding addressed by the WordPress patch. Its researchers inferred that whoever built them worked from the public code diff. That is a strong technical clue about the method. It is not proof of who created the probes.
There is no evidence that AI created this old bug, and no evidence that AI generated those exact observed requests. The bug sat in WordPress for nearly a decade. What has changed is the price and speed of the patch race: in general, AI plus ordinary automated tooling can help someone read a public diff, produce request variants, and scan large numbers of sites much faster and more cheaply than before.
Defenders get the same advantage. Automation can inventory a fleet and flag old core versions in minutes. AI can help sort log lines and group matching request patterns. A WordPress vulnerability scanner can catch exposed versions while a human checks the conditions and evidence. None of that replaces patching, but it cuts the boring search time dramatically.
Why “again” matters
September’s cadence isn’t an excuse to ignore update fatigue. It is the reason to build a routine that can handle it. Version 7.1.1 fixed 11 security issues on Thursday. Version 7.1.2 then closed a separate critical core route on Tuesday. If you checked the dashboard last week and mentally marked WordPress done for the month, check it again.
This isn’t the first short-notice core patch of the summer either. July’s separate wp2shell no-login WordPress chain demanded urgent action. In August, WordPress 7.0.4 fixed a different malicious-file-upload RCE that required an Author-level account plus Imagick and Ghostscript on the server. Those flaws did not share the same mechanics or access requirements. Grouping them together as “WordPress got hacked again” hides the details you need for a sensible response.
The common lesson is simpler: a critical core issue that works before login gets today’s attention, not a slot in next month’s maintenance list.
Update, verify, then test the business bits
Start with a quick backup or hosting snapshot. Then update WordPress to 7.1.2 and confirm the displayed version after it finishes. Don’t trust the fact that automatic updates are enabled. File permissions, hosting policy, a stuck maintenance state, or a failed background task can leave a site behind without making much noise.
If a major jump is genuinely impossible today, install the patched backport for your branch. Examples include 7.0.6, 6.9.9, 6.8.10, and releases all the way back to 4.7.37. The latest WordPress release remains the recommended destination, but the backported security release for your branch is far better than leaving a pre-auth core flaw open while you plan compatibility work.
Afterward, test the parts that make or lose money: checkout, payment return, contact form, booking form, and login. Our guide to updating WordPress safely gives the longer routine. For this release, keep the pre-update check quick. Don’t turn a perfect staging plan into a reason to postpone the patch for seven days.
If the site was exposed before you patched
Review requests to / or /index.php, in query strings and POST bodies, where pagename contains double-encoded traversal such as %252e%252e and appears with a page_id that resolves to a real page. If response-body or WAF captures are available, look for unexpected OPML or other core-file output from a normal page URL. Preserve the relevant evidence before rotation wipes it.
A matching probe does not equal compromise. It may only show that a scanner knocked on the door and tested the response. Successful inclusion, an unexplained file change, a new administrator, or suspicious PHP execution is different and deserves deeper inspection.
- Confirm the old and new WordPress versions and the exact update time.
- Save web, PHP, firewall, and hosting logs around suspicious requests.
- Check the active theme for a top-level
page-*directory. - Escalate if logs or file changes suggest an inclusion actually succeeded.
If you manage several sites, this is where regular WordPress maintenance earns its keep: fleet-wide version checks, backups, deployment, and quick tests happen as one job instead of five dashboard reminders you hope to remember.
The new rule is same-day
WordPress 7.1.2 is a second update in five days. Annoying? Absolutely. But active reconnaissance began in under five hours, and public patches now double as a map for both defenders and scanners.
Use a plain rule for critical no-login core flaws: back up, patch, verify, and test on the same day. Then inspect the evidence if your site was reachable during the gap.
You updated last week. Update again.