On 22 September 2026, WordPress shipped 7.1.2, a security-only release fixing one critical bug in how core resolves page templates. Three days later, on 25 September, CISA added the flaw, CVE-2026-87902, to its Known Exploited Vulnerabilities catalogue, citing evidence of active exploitation. If you run a marketing site, docs site or blog on WordPress, and many SaaS companies do, this is the one to check today rather than this week.
What the bug actually is
The flaw sits in get_page_template(). When WordPress builds its list of candidate template files for a page, one of them comes from the pagename value in the URL. With a crafted, double-encoded directory traversal in that parameter, an unauthenticated attacker can make WordPress include a readable PHP file that lives outside the active theme's directories. No login, no user interaction. It is scored 9.2 under CVSS v4.0.
WordPress's own advisory is careful to say that the file inclusion only becomes remote code execution when "relevant pre-conditions for both the server environment and the active theme" are met. Patchstack's write-up spells those out:
1. The theme condition. The active theme has a top-level directory whose name starts with page-, such as a page-templates folder. Patchstack says legacy default themes and a number of popular third-party themes ship exactly that.
2. The server condition. PHP has register_argc_argv enabled, and a useful PHP file to include is sitting on disk — PEAR's pearcmd.php is the notable one. Patchstack reports that register_argc_argv is on by default in the official Docker images and in cPanel with PHP below 8.5, which is why this is not a theoretical corner case.
The file inclusion part works regardless. The code-execution part depends on those two lining up.
Who is affected
Every release from 4.7.0 through 7.1.1. The fix is in 7.1.2 and was backported to every branch still eligible for security fixes, down to 4.7 — Cyber Kendra lists 7.0.6, 6.9.9, 6.8.10 and 4.7.37 among them. The bug was reported through WordPress's HackerOne programme in July by researcher Robert Ressl.
One small discrepancy to be aware of: WordPress.org and Patchstack date the release to 22 September, while Help Net Security and Cyber Kendra give 23 September. The difference is almost certainly time zones and publishing lag; the version numbers are what matter.
Is it really being exploited?
CISA says yes, and CISA does not add entries to the KEV catalogue on speculation. Help Net Security reports that reconnaissance probes started within the first day or two after the patch, that attackers then moved to active exploitation using pearcmd.php to write malicious files, and that attack traffic grew to more than ten times its initial volume within 24 hours. Patchstack, writing on release day, had not documented exploitation and deliberately did not publish a working request — that changed quickly, which is the usual pattern once a core patch diff is public.
What to do today
Confirm the version, do not assume it. WordPress says sites with automatic background updates will update themselves, but managed hosts, pinned versions, Docker images and "we turned auto-updates off after a plugin broke" are all common. Check Dashboard, then Updates, or look at the version in wp-includes/version.php. You want 7.1.2 or the patched release on your branch.
Check your exposure while you wait. If you cannot patch immediately, answer Patchstack's two questions: does your active theme have a top-level folder starting with page-, and is register_argc_argv enabled? If both are yes, treat the site as high risk.
Use the interim mitigations only as a bridge. Ressl's suggested stopgaps are disabling register_argc_argv for web requests, removing unused PEAR files and tightening PHP write permissions. He is explicit that none of these replace the patch.
If the site was unpatched after 22 September, look for signs of compromise. CISA's guidance for federal agencies is to check whether a system was compromised before the patch went on, which is sensible for everyone. Look for unexpected PHP files in writable directories, new admin users, and access-log requests with unusual pagename values.
Think about what the marketing site can reach. A WordPress box that shares credentials, a database server or a VPC with your product is a much bigger problem than one that is isolated. If yours is not isolated, this is a good week to change that.
The wider pattern
This is not the first serious WordPress core issue this summer: Cyber Kendra notes the "wp2shell" pair (CVE-2026-63030 and CVE-2026-60137) in July and "XSS2Shell" (CVE-2026-64638) in August. Core bugs are rarer than plugin bugs, but when they land they hit everyone at once, and the gap between patch and exploitation is now measured in hours.
The bottom line
CVE-2026-87902 lets anyone on the internet make WordPress include PHP files it should not, and on common server set-ups that becomes code execution. CISA has confirmed exploitation. Get every WordPress install you own onto 7.1.2 or its backported equivalent today, check whether your theme and PHP config match the RCE conditions, and if anything sat unpatched over the last week, go looking for files you did not put there.