WordPress 7.1.2 was released on 22 September 2026 to fix CVE-2026-87902, a critical flaw in page-template resolution. WordPress says the issue can allow an unauthenticated attacker to include a readable local PHP file outside the active theme directories and, when specific theme and server conditions are present, reach remote code execution. Since disclosure, researchers have reported both probing and active exploitation attempts.
What the WordPress 7.1.2 security update fixes
The vulnerability sits in the logic WordPress uses to choose a page template. According to the official WordPress advisory, an attacker can influence that process so that WordPress tries to load a local PHP file outside the normal theme path. The issue is tracked as CVE-2026-87902 and carries a CVSS 4.0 score of 9.2.
Patchstack says WordPress Core versions from 4.7.0 through 7.1.1 are affected. WordPress 7.1.2 contains the fix, and patched releases were also issued for older supported branches, including 7.0.6, 6.9.9 and 6.8.10, with backports continuing through the branches eligible for security fixes.
This is not a case where every unpatched site can immediately be taken over. Successful code execution depends on additional conditions. Researchers describe two important prerequisites: the active parent or child theme needs a top-level directory whose name begins with page-, and the server must contain a suitable readable PHP file that can be abused when included. Those conditions reduce exposure, but they do not make the issue theoretical.
Active exploitation changed the risk calculation
The most important development came after the patch was published. Patchstack reported probing on 22 September, less than five hours after the release. By 24 September, The Hacker News reported that Previdian had observed attempts going beyond harmless reconnaissance and trying to use local PHP files to write attacker-controlled code to disk.
The timing matters. Once a security patch is public, attackers can compare the old and new code and work backwards from the change. CVE-2026-87902 is a clear example of how quickly that process can happen. Patchstack said the early requests matched the encoding addressed by the patch, suggesting that attackers were working from the public code difference rather than discovering the weakness independently.
For site owners, that means the sensible response is no longer to wait for evidence that a particular site is being targeted. The patch is available, exploitation activity has been reported, and the vulnerable code is in WordPress Core rather than in an optional plugin.
What site owners should check now
The first step is simple: confirm that the site is running WordPress 7.1.2 or the corresponding patched release for its branch. Do not assume an automatic update completed successfully. Check the installed version in the Dashboard or through the site’s normal management tooling.
- Patch first: update WordPress Core to the current secure release for the branch you are using.
- Verify, do not assume: confirm the version after the update, especially across fleets of sites managed by an agency, hosting panel or central management service.
- Review web logs: look for unusual requests involving page-template resolution or traversal-shaped pagename values around and after 22 September.
- Check for unexpected PHP files: if the site was exposed before patching, review recent file changes and suspicious files in writable locations.
- Inspect the active theme: a top-level directory beginning with page- is one of the conditions researchers have identified for exploitation.
- Prefer the current WordPress branch: older branches received security backports, but WordPress notes that only the latest version is actively supported.
Teams running several WordPress sites should treat this as an inventory problem as much as a patching problem. A single forgotten staging site, old microsite or customer instance can be more exposed than the main production site if it has not received the same maintenance attention.
Why automatic updates help but do not remove the need to verify
WordPress says sites that support automatic background updates should begin receiving the security release automatically. That reduces the vulnerable window for many installations, but it is not a substitute for checking the result. Updates can be delayed or blocked by hosting configuration, filesystem permissions, maintenance settings or site-management policies.
For businesses that depend on WordPress for e-commerce, lead generation or customer portals, a simple verification process is worth formalising: record the WordPress version, confirm the update completed, check the public site for obvious breakage and retain a known-good backup. Security updates of this severity should not sit in the same queue as routine cosmetic maintenance.
What developers should take from the fix
Patchstack’s analysis is useful because WordPress did more than add a narrow check around the reported input. The 7.1.2 change also adds broader containment logic so resolved template paths must remain inside allowed theme locations. That is a stronger defensive design than fixing one exact traversal path.
For developers, the lesson is familiar but important: file-resolution code should enforce where a resolved path is allowed to land, not only try to identify known-bad input strings. A validation rule can miss an unexpected encoding or alternate path; containment provides a second boundary.
Critical analysis
In our assessment, CVE-2026-87902 deserves urgent attention, but the risk should be described precisely. The vulnerability is unauthenticated and the potential impact is severe, yet remote code execution is conditional on the active theme and server environment. Calling every unpatched WordPress site trivially exploitable would overstate the evidence.
The available evidence nevertheless argues strongly against delay. WordPress issued an immediate security release, Patchstack observed probing within hours, and independent reporting documented attempts that moved towards active code execution. Once exploitation activity is visible, debating whether a particular configuration is likely to be vulnerable is less useful than installing the patch and then checking the exposure window.
A key limitation is that public telemetry cannot tell an individual site owner whether their own installation was targeted or compromised. That requires local evidence: version history, access logs, file-integrity data and, where appropriate, endpoint or hosting telemetry. The right operational sequence is therefore patch, verify, review recent activity and investigate further if the evidence warrants it.
Sources
- WordPress.org — WordPress 7.1.2 Release, 22 September 2026.
- Patchstack — WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE, 22 September 2026.
- Patchstack — CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch, 22 September 2026.
- The Hacker News — Attackers Exploit WordPress CVE-2026-87902 Within Hours of Disclosure, 24 September 2026.
Leave a Reply