Wordify
Get started
← Back to blog
· by The Wordify Team · in WordPress News

WordPress 7.1.2: one critical fix, and two conditions decide whether it touches you

WordPress security release: WordPress 7.1.2. One critical fix, and two conditions decide exposure.

WordPress 7.1.2 landed on September 22, 2026, five days after 7.1.1. It fixes one security issue, WordPress rates it critical, and an attacker doesn't need to log in to use it. WordPress recommends updating immediately. Do it now.

Whether it can reach your site depends on two conditions, one about your theme and one about your server. You can check the theme in a minute. Most site owners can't see their server's settings, so checking the conditions won't tell you it's safe to skip the update.

What shipped

The release was led by John Blackbourn. It contains one security fix and nothing else: no features and no maintenance fixes.

Between the 7.1.1 and 7.1.2 tags there are four commits and six changed files, but only one of those files is code: wp-includes/template.php, with 72 lines added and six removed. The rest are version bumps and the About page. The version documentation lists that single file as revised, with no bundled packages updated.

The issue is CVE-2026-87902 (GitHub advisory GHSA-7hp8-65ch-5whp). The advisory scores it 9.2 under CVSS 4.0, classifies it as CWE-98, PHP file inclusion, and credits Robert Ressl with reporting it.

What the flaw does

When someone visits a page, WordPress works out which template file in your theme should render it. For pages, that lookup runs through get_page_template(), which builds a list of candidate file names, and locate_template(), which walks the list and loads the first one that exists.

The page name the visitor asked for feeds into that candidate list. According to the advisory, an attacker with no account can shape that name so the lookup steps outside the theme and includes a PHP file from somewhere else on the server instead. Including a PHP file runs it. The two conditions below decide whether the lookup can reach outside the theme, and whether the server has a file an attacker could use.

What the patched code now checks

The fix changes two places:

  • At the source. get_page_template() only adds the decoded page name as a template candidate if it passes validate_file(), WordPress's long-standing check that rejects .. directory traversal.
  • At the point of loading. A new private helper, _wp_is_template_path_allowed(), checks any candidate path that contains ... It resolves the real location with realpath() and only allows it if it lands inside the child theme, the parent theme or WordPress's own wp-includes/theme-compat fallbacks. It also allows the folder directly above a theme that lives in a subdirectory. locate_template() now runs every candidate through this check and skips any that fail, instead of taking the first file that happens to exist.

The function's documentation now reads: "A template name containing .. is only located if it resolves inside the theme."

We think the double check is deliberate. Blocking the bad name where it enters closes the reported path. Checking again where files are loaded also closes any other route that hands locate_template() a path containing ... Paths without .. skip the new check, so normal theme template loading shouldn't change.

Condition one: your theme

Per the advisory, the active theme, or its parent theme if you're running a child theme, has to contain a top-level folder whose name starts with page-. A folder called page-templates is the common case.

Plenty of themes keep their page templates in a folder like that. The advisory names five: Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney. Twenty Twelve and Twenty Fourteen are former default themes that shipped with WordPress itself.

To check your own site:

  1. Find your active theme's folder in wp-content/themes/, using SFTP, your host's file manager, or wp theme list --status=active if you have WP-CLI.
  2. Look at the folders directly inside it. Anything named page- something counts.
  3. If you're on a child theme, check the parent theme's folder too. A child theme inherits its parent's templates, so a page-templates folder in the parent is enough.

Other themes may have the same folder, so check for it whatever theme you run.

Condition two: your server

The second condition is that a PHP file the attacker can make use of has to exist on the server and be readable. The advisory names the known route: PEAR's pearcmd.php, which becomes usable when PHP's register_argc_argv setting is switched on.

PEAR is an old PHP package manager that still ships alongside PHP on a lot of systems. register_argc_argv is a setting that exists for PHP scripts run from the command line, and a web server doesn't need it. The advisory says it's switched on in two common setups:

  • The official php Docker image.
  • A default cPanel server running PHP older than 8.5.

Most site owners can't easily check this. You didn't choose your server's PHP build, you may not be able to read its configuration, and the setting can be changed in more than one place. PEAR is also only the route the advisory names. There may be others.

"I'm not on WordPress 7.1. Am I patched?"

Yes, as long as you take the update for your branch. You don't need a major version upgrade to get patched.

Every branch back to 4.7 was affected, and every one of them has a fix.

Your branch Affected by Update to
7.1 1 of 1 7.1.2
7.0 1 of 1 7.0.6
6.9 1 of 1 6.9.9
6.8 1 of 1 6.8.10
6.7 1 of 1 6.7.9
6.6 1 of 1 6.6.9
6.5 1 of 1 6.5.12
6.4 1 of 1 6.4.12
6.3 1 of 1 6.3.12
6.2 1 of 1 6.2.13
6.1 1 of 1 6.1.14
6.0 1 of 1 6.0.16
5.9 1 of 1 5.9.18
5.8 1 of 1 5.8.17
5.7 1 of 1 5.7.19
5.6 1 of 1 5.6.21
5.5 1 of 1 5.5.22
5.4 1 of 1 5.4.23
5.3 1 of 1 5.3.25
5.2 1 of 1 5.2.28
5.1 1 of 1 5.1.26
5.0 1 of 1 5.0.29
4.9 1 of 1 4.9.33
4.8 1 of 1 4.8.32
4.7 1 of 1 4.7.37
4.6 and earlier No longer receives security updates Upgrade

WordPress's version API now marks every earlier patch on every branch as insecure, including 7.1.1, 7.0.5 and 6.9.8. WordPress is also clear that only the most recent version is actively supported. WordPress describes the backports as a courtesy.

"Backports in progress" versus what actually shipped

The release announcement says the backports "are in progress and will ship as they become ready".

Every other source says they've shipped. The version documentation lists all 24 backports, the advisory gives patched versions for every branch, the version API reports a patched release on each of them, and the git tags are all dated September 22. Every branch had its fix within about three hours of 7.1.2.

The most likely explanation is that the announcement was written before the older tags landed. The table above shows what's available now.

What to do

  1. Take the update, or confirm it's already happened. Sites with automatic background updates have most likely updated on their own. Check rather than assume, especially where a plugin or a constant has switched auto-updates off.
  2. Confirm the version against your branch. In WP Admin, go to Dashboard, then Updates. Match what you see against the table above. On 6.9, "patched" means 6.9.9, not 7.1.2.
  3. Check your theme for a page- folder, including the parent theme. You should update either way, but it tells you whether the site was exposed before you did.
  4. Include staging copies and old clones. A forgotten staging site or an old copy made before a redesign runs code like any other WordPress install, and it's often still on an old theme.
  5. Ask your host about register_argc_argv and PEAR. Specifically, whether register_argc_argv is enabled for web PHP. It's worth asking even after you've updated, because web PHP doesn't need that setting.

If you're on Wordify, this one has already been handled

Automated Safe Updates treats a security release differently from a routine one. Routine updates wait for your update window. A release that closes a known vulnerability doesn't: it goes out as soon as it's available.

WordPress flags this for us directly. Its version API marked 7.1.1, 7.0.5, 6.9.8 and every other earlier patch as insecure, and that signal is what fast-tracks the update rather than holding it for the small hours. Sites with it switched on were patched within hours of the release.

Sites on older branches take their branch's backport rather than a major upgrade, so a site on 7.0 moves to 7.0.6 and a site on 6.9 moves to 6.9.9.

Every site gets a verified restore point before the update. Wordify then applies the update, loads the site and compares what comes back with what came back before. If that health check fails, the update is rolled back automatically.

Some sites always need a look by hand, and those land on your Tasks page rather than sitting silently.

On the server condition: our platform isn't exposed. When we checked on September 23, register_argc_argv was disabled for all web PHP on every server. Update anyway. The server setting only blocks one known route to exploit the flaw, and the update removes the flaw itself.

Automated Safe Updates is on every plan at no extra cost. Here's how it works.

Common questions

Is WordPress 7.1.2 urgent?

Yes. Update today. It needs no account, and one of its two conditions is something most site owners can't check, so there's no quick way to rule yourself out. The update is one file, in-branch, and security-only, which makes it about as low-risk as updates get.

My theme has no page- folder. Can I wait?

You're very likely not exposed through the route the advisory describes. Update anyway, and soon. Themes change, child themes get swapped, and "no page- folder" is a fact about the theme you're running today.

I use Neve, Hestia or Sydney. What now?

Update WordPress core. The fix is in core, not in the theme, so there's no theme update to wait for and no reason to switch themes. Once core is on the patched version for your branch, the theme's page- folder stops being a way in. If you manage several client sites on these themes, put them first in the queue.

Will WordPress update itself?

Sites that support automatic background updates pick up minor and security releases on their own. Confirm it rather than assume it, because auto-updates are easy to switch off and easy to forget about.

Does this affect plugins?

No. The patch is entirely in core's template loading, and the condition that matters is your theme's folder structure. Plugin vulnerabilities are patched on their own schedules, so keep your plugins updated too.

Will the fix break my theme's templates?

We don't think so. The new check only applies to template paths containing .., and normal theme templates don't use them. Templates in the child theme, the parent theme and WordPress's own fallbacks are all explicitly allowed. If a theme was deliberately loading templates from outside its own folders using .., that stops working, because it's what the fix blocks.

Why is it critical if it needs conditions?

The score measures what happens when the conditions are met: code execution by someone with no account. The vector is AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H. It's reachable over the network, needs no privileges or user interaction, and the impact is high on confidentiality, integrity and availability. The conditions sit in one field, AT:P, CVSS 4.0's "attack requirements present". 7.0.4 also needed two conditions to be true, but it needed an account. This one doesn't.

The unglamorous point

Whether this reached your site came down to two things nobody chose on purpose. A theme folder called page-templates, which is a sensible place to keep page templates, and a PHP setting meant for the command line that some common server builds leave on.

The fix is one file, patched in every branch back to 4.7 within about three hours. Whether that helps you depends on the update reaching your sites, including the staging copy and the client site nobody has logged into since launch. We've written before about how short the gap between disclosure and exploitation has become, and a public diff for a flaw that needs no login is the situation that gap describes.

That's why Automated Safe Updates applies security releases as soon as they're out.

If you're not sure whether your sites are on a patched version, talk to us and we'll check with you.

More on this

Sources