WordPress 7.1.2 fixes a critical remote code execution flaw
Released on , WordPress 7.1.2 is a security-only release that closes one critical severity vulnerability in the way WordPress resolves page templates, and the release team recommends updating immediately. Read the WordPress.org release note here.
This lands five days after WordPress 7.1.1 patched 11 security flaws in one go, and it has the opposite shape. There is one fix, one changed file (wp-includes/template.php), and no bug fixes riding along. The security advisory rates it Critical at 9.2 out of 10 on CVSS version 4, and unlike most of the 7.1.1 issues, which needed a logged-in account, this one needs no login at all.
The reason it is not a universal emergency is that it only reaches remote code execution when conditions on both the theme and the server line up. That makes 7.1.2 a release to apply today on every site, and a short set of checks worth running on the sites that do meet those conditions.
How the vulnerability works
Every time WordPress serves a page, it has to decide which PHP template file in the theme should render it. That decision follows the template hierarchy, and for pages it is handled by get_page_template(), which builds a list of candidate template files and loads the first one it finds. The advisory, tracked as CVE-2026-87902, describes an unauthenticated path traversal in that resolution step: a visitor with no account can steer it into including a readable local .php file that sits outside the active theme's directories.
In plain English, WordPress can be tricked into running a PHP file that was never meant to be a template. The advisory files it under CWE-98, improper control of the filename in a PHP include or require statement. On its own, including an arbitrary file is only as dangerous as the files available to include, which is why the advisory is precise about what else has to be true before this becomes remote code execution.
There are two preconditions. The first is on the theme: the active theme, or its parent if a child theme is in use, must contain a top-level directory whose name starts with page-, such as page-templates. That is a common way of organising custom page templates, and the advisory names the legacy Twenty Twelve and Twenty Fourteen default themes plus the popular third-party themes Neve, Hestia and Sydney as meeting it. The second is on the server: a PHP file that turns inclusion into code execution has to exist and be readable by the web server account. The advisory names the well-known route, PEAR's pearcmd.php, which becomes usable when PHP's register_argc_argv setting is on. It states that the official PHP image for Docker is affected, and that the default cPanel configuration is affected when a PHP version earlier than 8.5 is in use.
The CVSS vector reflects all of this. The attack is over the network, low in complexity, needs no privileges and no user interaction, and has high impact on confidentiality, integrity and availability. The one qualifier is "attack requirements present", which is how CVSS version 4 records that the theme and server conditions above have to be met first.
Which sites are actually exposed
A brochure site on a modern block theme with no page- directory at the top of the theme folder does not meet the theme precondition. It still needs 7.1.2, because the release is the fix and there is no reason to sit on it, but it is not an incident. The same goes for a site whose host has register_argc_argv switched off for web requests and no PEAR installation on the box, although that is harder to confirm from the WordPress dashboard alone.
An older client site that still runs Twenty Fourteen, or one built on Neve, Hestia or Sydney, on a cPanel server running a PHP version earlier than 8.5, is the combination the advisory describes. That is the site to check first, because the theme condition is met by name and the server condition is met by default. A site deployed from the official PHP Docker image is in the same position on the server side, so its theme is the deciding factor.
Child themes need a second look. The advisory's theme condition covers the active child or parent theme, so a child theme with a tidy folder structure does not help if the parent theme it inherits from has a page-templates directory. When auditing, list both folders.
How the fix reaches your site
WordPress has shipped minor releases through automatic background updates by default since version 3.7, and the release note confirms that sites which support background updates will start updating on their own. On a standard install with nothing overridden, 7.1.2 applies itself. For most sites the practical question is therefore not whether to update but whether the update actually happened.
That default is switched off more often than people expect. Some managed hosts define WP_AUTO_UPDATE_CORE as false and run core updates on their own schedule, Composer-managed builds pin the core version in a lockfile, and plenty of agencies turned automatic updates off on a site years ago after a fragile plugin broke on a point release. Those sites will stay on 7.1.1 until somebody updates them.
The fix has been backported to every branch from 4.7 upwards, and every one of those branches was affected. The patched versions are 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 and 4.7.37, all listed on the WordPress 7.1.2 version page. WordPress 4.6 and earlier no longer receive security updates, so there is no patched version for them at all. WordPress describes the older-branch releases as a courtesy and reminds users that only the most recent version is actively supported.
What this means for UK site owners and agencies
If you look after more than a handful of WordPress sites, the job this week is verification rather than panic. Confirm the running core version on every site against the patched number for its branch, and do not assume the automatic update ran just because it normally does. The sites most likely to have been missed are the same ones most likely to meet the preconditions: older builds on legacy themes, on hosting nobody has reviewed for a while.
For any site that is not yet patched, check the theme and the server together. Look in the active theme folder, and the parent theme folder if there is one, for a top-level directory whose name starts with page-. Then ask the host, or check a phpinfo() output, whether register_argc_argv is on for web requests and whether PEAR is installed. A site that meets both conditions should be updated before anything else on the list, and it is worth reviewing whether it was altered before the update went on.
That review has a UK compliance angle. Under UK GDPR, a personal data breach that is likely to put people's rights and freedoms at risk has to be reported to the ICO within 72 hours of the organisation becoming aware of it. A site that takes enquiry forms, orders or account sign-ups holds exactly that kind of data, so a compromise found during this audit is not just a technical clean-up. Routine patch verification across a portfolio is the core of a WordPress maintenance arrangement, and releases like this one are why it exists.
Practical considerations
Updating closes the hole but does not undo anything that happened before the update. Neither the release note nor the advisory says the flaw has been exploited in the wild, and the advisory does not offer a workaround short of updating. The details are now public, though, and the preconditions are specific enough to scan for, so a site that meets them and stayed unpatched after 22 September deserves a look for unfamiliar PHP files, new administrator accounts and recently modified files outside the normal update pattern.
Keep the severity score in proportion. A 9.2 with "attack requirements present" means a large share of WordPress sites cannot be exploited this way at all, but you cannot tell which share yours is in without checking a theme folder and a server setting you would not normally look at. On most sites the update is quicker than the check, so the sensible order is to update first and investigate second. It is also the second security release in a week, after 7.1.1, and the WordPress 7.1 branch that shipped with WordPress 7.1 "Mary Lou" in August has now had two rounds of security fixes in its first five weeks.
FAQ
What does WordPress 7.1.2 fix?
One critical severity vulnerability, CVE-2026-87902. An unauthenticated visitor can make WordPress's page-template resolution include a readable local PHP file outside the active theme's directories, which can lead to remote code execution when certain theme and server conditions are met. It is a security-only release and the only file changed is wp-includes/template.php.
Is my WordPress site vulnerable to CVE-2026-87902?
Every WordPress branch from 4.7 to 7.1 carried the flaw until the patched releases of 22 September, but reaching code execution needs two conditions. The active theme, or its parent theme, must have a top-level directory whose name starts with page-, and a PHP file that turns inclusion into code execution must be readable on the server. The advisory names PEAR's pearcmd.php with register_argc_argv switched on as the known route.
Which themes meet the theme condition?
The advisory names the legacy Twenty Twelve and Twenty Fourteen default themes and the third-party themes Neve, Hestia and Sydney. Any other theme with a top-level folder such as page-templates meets it too, so check your own theme folder, and the parent theme folder if you use a child theme.
Do I need to update WordPress manually?
Not if automatic background updates for minor releases are working, which is the default since WordPress 3.7. You do need to act if WP_AUTO_UPDATE_CORE is set to false, if your host stages core updates on its own schedule, or if the core version is pinned in a Composer lockfile. Either way, confirm the version number rather than assuming.
Which WordPress versions contain the fix?
WordPress 7.1.2 on the current branch, plus backports on every branch back to 4.7: 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16 and older point releases down to 4.7.37. WordPress 4.6 and earlier receive no security updates.
Is the vulnerability being exploited?
Neither the WordPress.org release note nor the GitHub advisory says so. The details are public, however, and the conditions are specific enough to scan for, so a site that meets them and was not patched promptly is worth checking for unfamiliar PHP files, new administrator accounts and unexpected file changes.
