WordPress 7.1.2 fixes CVE-2026-87902: when an update becomes an incident

WordPress has published security release 7.1.2, fixing the critical CVE-2026-87902 vulnerability in Core. Under specific conditions, an unauthenticated attacker can make page-template resolution include a readable local PHP file outside the active theme directory. That first creates a local-file inclusion path and, when further server conditions are present, can lead to remote code execution.

For a business owner, the key message is simple: asking whether “WordPress updates automatically” is not enough. The organisation must confirm the version on every running instance, establish whether the environment meets the attack preconditions and check for signs of compromise during the exposure period.

What happened on 22 September

The official WordPress 7.1.2 announcement classifies the issue as critical and recommends an immediate update. The fix is in the latest release and was also backported, as a courtesy, to security branches as far back as WordPress 4.7.

Affected versions include WordPress 7.1.0–7.1.1, 7.0.0–7.0.5, 6.9.0–6.9.8 and the older lines listed in the official GHSA-7hp8-65ch-5whp advisory. Corresponding fixed releases include 7.1.2, 7.0.6, 6.9.9, 6.8.10 and the appropriate backports for older branches.

That does not make a years-old WordPress release safe because it received one backport. WordPress notes that only the latest version is actively supported. An old Core release, PHP runtime, theme or plug-in may contain other known weaknesses.

When the flaw can become code execution

The advisory describes two important preconditions. The active parent or child theme must have a top-level directory whose name begins with page-, such as page-templates. A local PHP file must also exist on the server, be readable by the web process and be usable to produce a more serious consequence.

Examples named in the advisory include the legacy Twenty Twelve and Twenty Fourteen themes and popular third-party themes such as Neve, Hestia and Sydney. They illustrate the directory condition; they are not a complete list of vulnerable sites. The presence of one named theme alone also does not prove successful exploitation.

The official score is 9.2 under CVSS 4.0. The attack is network-based and requires neither an account nor user interaction, but it does require a particular combination of theme layout and server environment. “Conditional RCE” therefore means neither “every site is compromised” nor “we can wait.”

Today’s action plan for a site owner

1. Find every installation. Include the main site, shop, blog, campaign landing pages, test environments and old sites still hosted by an agency.
2. Confirm the deployed version. Use the dashboard, filesystem or hosting management data. In a cluster, verify every node rather than one screen.
3. Take a controlled backup. Preserve the database, files and configuration before changing the service, but do not treat a backup as a substitute for patching.
4. Move to the correct release. Prefer the currently supported line. If only a backport can be deployed today, give the modernisation work an owner and a date.
5. Clear caches and validate traffic. A CDN, opcode cache, container image or old replica may continue serving previous code.
6. Test critical journeys. Check forms, sign-in, checkout, payments, outbound mail and integrations after the update.
7. Preserve logs. Do not allow short retention to delete the evidence needed to determine whether exploitation was attempted.

If an agency operates the site, ask for the exact deployed version, update time, list of covered instances and validation result. “Automatic updates are enabled” is not evidence that the job succeeded.

What to check for compromise

Look for new or changed PHP files in theme, plug-in, uploads, mu-plugins and root directories. Compare Core and extensions with clean packages. Review new administrators, application passwords, cron jobs, active-theme changes, unusual HTTP requests, and server-side processes and outbound connections.

Do not build detection around a single URL string copied from the internet. The official description establishes the bug class and preconditions, not an exhaustive list of every exploitation method. Correlation is more valuable: an unusual request followed by PHP execution, a changed file, a new administrator session and an outbound connection within a short window.

If there are signs of code execution, installing the update does not close the incident. Isolate the instance, preserve evidence, rebuild from a trusted artefact and assess the secrets available from the host: database credentials, WordPress salts, API keys, mail and payment credentials, and deployment tokens.

What this means for the business

A company website is more than marketing material. It often processes leads, applicant details, orders, payments and CRM integrations. Compromise can alter bank details, sign-in forms, analytics code or the content customers see.

The risk owner should know the answers to four questions: who maintains the site, how quickly critical fixes are deployed, how the company validates that no compromise occurred, and how it restores service without restoring an infected backup. Those are ownership questions, not only technical questions.

Source facts and Breachroad assessment

WordPress confirms the critical vulnerability, immediate-update recommendation and backports. The GHSA confirms CVE-2026-87902, the 9.2 score, affected versions, theme and server preconditions, and conditional RCE. The public sources do not establish that every installation is vulnerable or that mass exploitation has occurred.

The sequencing of inventory, log preservation, testing and incident response is Breachroad’s assessment based on the normal impact of code execution in a web application. Our WordPress security guide covers the underlying hygiene. Application teams can practise these decisions in web application security training, while an independent web application penetration test can validate real exposure.