Direct answer: If your site runs WordPress 7.1.1 or any earlier unpatched branch, update WordPress core now. WordPress 7.1.2 fixes CVE-2026-87902, a critical vulnerability that can let an unauthenticated attacker include a readable local PHP file and, when specific theme and server conditions are present, achieve remote code execution.[1][2]
CISA added CVE-2026-87902 to its Known Exploited Vulnerabilities catalog on September 25, 2026, which means this is not merely a theoretical flaw.[3][5] Back up first, patch every live, staging, and forgotten clone, then check the site and logs for signs of compromise.
If you recently followed the WordPress 7.1.1 update guide, this new security release supersedes it: verify that the site has moved again to 7.1.2.
5-minute action checklist
- Check your core version: In WordPress, open Dashboard → Updates. If you are on the 7.1 branch, the safe release is 7.1.2.[1][2]
- Take a fresh backup: Include both the database and site files. Confirm where the backup is stored before changing production.
- Update WordPress core: Use Dashboard → Updates → Update Now, your host’s control panel, or your normal managed deployment process. Sites that allow automatic background core updates may already be updating, but verify instead of assuming.[1]
- Purge caches: Clear your WordPress cache, server cache, and CDN cache after the update.
- Test critical paths: Check the homepage, login, editor, contact forms, search, checkout, payment callbacks, and any custom templates.
- Inspect for compromise: Review administrator accounts, modified PHP files, security alerts, access logs, unfamiliar scheduled tasks, injected pages, and unexpected redirects.
- Patch non-production copies: Staging sites, old migrations, demos, and abandoned subdomains can still be exposed.
Which WordPress versions are patched?
WordPress published fixes for the current branch and older supported security branches. Use the patched release for the branch you are already running; do not assume that “not on 7.1” means safe.[1][2]
| Current branch | Patched version |
|---|---|
| 7.1 | 7.1.2 |
| 7.0 | 7.0.6 |
| 6.9 | 6.9.9 |
| 6.8 | 6.8.10 |
| 6.7 | 6.7.9 |
| 6.6 | 6.6.9 |
| 6.5 | 6.5.12 |
| 6.4 | 6.4.12 |
| 6.3 | 6.3.12 |
| 6.2 | 6.2.13 |
| 6.1 | 6.1.14 |
| 6.0 | 6.0.16 |
| 5.9 | 5.9.18 |
| 5.8 | 5.8.17 |
| 5.7 | 5.7.19 |
| 5.6 | 5.6.21 |
| 5.5 | 5.5.22 |
| 5.4 | 5.4.23 |
| 5.3 | 5.3.25 |
| 5.2 | 5.2.28 |
| 5.1 | 5.1.26 |
| 5.0 | 5.0.29 |
| 4.9 | 4.9.33 |
| 4.8 | 4.8.32 |
| 4.7 | 4.7.37 |
WordPress says the fix was backported through the 4.7 branch, while also reminding users that only the latest WordPress version is actively supported.[1] Treat a backport as an emergency security fix, not a reason to remain indefinitely on an old branch.
What CVE-2026-87902 does
The vulnerability affects WordPress page-template resolution in get_page_template(). Under the documented conditions, an unauthenticated attacker can make WordPress include a chosen readable local .php file located outside the active theme directories.[2] If an exploitable PHP file is available on the server, that local file inclusion can become remote code execution.[2]
The WordPress advisory rates the issue critical with a CVSS score of 9.2. It lists network access, no privileges, and no user interaction among the exploitability characteristics, while noting that attack requirements are present.[2]
Is every WordPress site exploitable?
No. The vendor advisory documents two important preconditions:[2]
- The active parent or child theme has a top-level directory whose name begins with
page-, such aspage-templates. - A suitable readable local PHP target exists on the server.
The advisory names the legacy Twenty Twelve and Twenty Fourteen themes and some third-party themes as examples that meet the theme-directory condition. It also describes server configurations that can provide a usable PHP target.[2]
Those conditions should not be used as an excuse to delay. CISA added the flaw to the KEV catalog on September 25, with a federal-agency remediation due date of September 28, and the Canadian Cyber Centre says open-source reporting indicates exploitation in the wild.[3][5] New Zealand’s NCSC likewise advises affected organizations to patch promptly and investigate unauthorized access or compromise.[4]
Safe update procedure for business sites
1. Record the current state
Note the WordPress version, active theme and child theme, PHP version, caching layers, and recent plugin updates. Take screenshots of any important settings that are difficult to reconstruct.
2. Back up files and database
A database-only backup is not enough for incident recovery. Include WordPress core, wp-content, configuration files, server rules, and the database. If the site handles orders or leads, minimize the time between backup and deployment.
3. Update core without delaying for a full redesign
This is a focused security update. Do not bundle it with a theme migration, PHP upgrade, plugin cleanup, or layout overhaul unless your environment requires that dependency. One controlled change is easier to test and reverse.
4. Purge caches in order
Clear the WordPress cache first, then host/server cache, then CDN cache. Confirm that logged-out visitors receive the new response rather than an old cached error page.
5. Run a focused smoke test
Test:
- public pages and custom page templates
- WordPress login and administrator access
- post/page editing and media uploads
- contact and lead forms
- ecommerce cart, checkout, payment and email notifications
- multilingual routes, if used
- scheduled tasks and webhooks
- mobile and desktop navigation
6. Review evidence, not just appearance
A homepage loading correctly does not prove the site is clean. Check your security plugin or host alerts, web access and PHP error logs, recently changed files, new administrator users, unusual scheduled jobs, unexpected redirects, and unknown PHP files.
Updating closes the vulnerable code path; it does not prove that an already exploited site is clean. If you see indicators of compromise, preserve logs and backups before deleting files, rotate WordPress and hosting credentials, refresh salts, and involve a qualified incident responder.
WP-CLI commands
Check the installed version:
wp core version
Create a database backup before the update:
wp db export before-wordpress-security-update.sql
Update core and confirm the result:
wp core update
wp core version
wp core verify-checksums
Run these commands from the correct WordPress directory and under the appropriate system account. Managed hosts may require their own update workflow.
FAQ
Does WordPress 7.1.2 fix CVE-2026-87902?
Yes. WordPress 7.1.2 contains the fix for CVE-2026-87902.[1][2]
Is CVE-2026-87902 being exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on September 25, 2026, and Canada’s Cyber Centre reports that open-source reporting indicates exploitation in the wild.[3][5]
Can an attacker exploit it without logging in?
The WordPress advisory says an unauthenticated attacker can trigger the vulnerable page-template behavior when the required theme and server conditions are present.[2]
Do I need to update if automatic updates are enabled?
Verify the installed version. WordPress says automatic background updates will begin on eligible sites, but disabled updates, file permissions, hosting controls, or update failures can prevent completion.[1]
What if my site is on WordPress 6.x or an older branch?
Install the patched release for your branch from the table above, then plan a controlled upgrade to the latest supported WordPress version. The security fix was backported through 4.7, but WordPress states that only the latest version is actively supported.[1][2]
Should I restore a backup after updating?
Not automatically. A backup may also contain vulnerable or compromised code. Restore only when necessary, document why, and patch and investigate the restored environment before returning it to service.
Bottom line
Patch now, verify the installed version, test the site, and investigate suspicious activity. The key change since the original WordPress release is that CISA now lists CVE-2026-87902 as known exploited, raising the urgency for every internet-facing WordPress installation.[3][5]