WordPress 7.1.2 patches a critical flaw. No login needed, every version since 4.7 affected

TL;DR

On September 22, 2026 WordPress 7.1.2 shipped as a security release with a single fix. It patches CVE-2026-87902 in core, rated 9.2 on CVSS 4.0, which is critical. The attacker needs no account and no user interaction, just the public address of your site. Every version from 4.7.0 through 7.1.1 is affected, nearly ten years of releases. A full server takeover requires additional conditions on the theme and PHP side, but a large share of typical hosting setups meets them. There is no workaround. Updating is the only fix. The patch was backported to every supported branch, so a site on an older WordPress gets the fix without jumping to 7.1. Below you'll find what the flaw is, the list of conditions, a procedure for checking your own site and what to look for in the logs.

What was fixed

The flaw sits in the mechanism WordPress uses to pick the theme file that renders a page. One of the request parameters skipped the check that stops attempts to escape the theme directory. As a result, an unauthenticated attacker could make WordPress include any readable PHP file from the server's disk, including files outside the theme directories. The weakness class is CWE-98, improper control of a filename in an include statement.

Including a foreign PHP file is already a serious problem, because that file runs with the web server's privileges. If the server holds a file that executes commands passed to it when invoked the right way, the flaw turns into remote code execution, meaning a full takeover of the site and everything else on the same hosting account.

The vulnerability was discovered and responsibly disclosed by Robert Ressl. The fix landed in WordPress 7.1.2 and in every older branch that still receives patches, all the way back to 4.7.

When your site is actually at risk

The official advisory and the Patchstack analysis list three conditions that must coincide for the attack to end in code execution. Each of them is common on its own.

A theme with a directory starting with page-. The active theme, child or parent, has a top-level subdirectory whose name starts with page-, most often page-templates. This is how the legacy default themes Twenty Twelve and Twenty Fourteen are built, along with popular commercial themes including Neve, Hestia and Sydney. Neve and Hestia are among the most popular free themes in the WordPress.org directory.

The PHP setting register_argc_argv enabled. This interpreter option is on by default in the official PHP Docker images and in cPanel on PHP versions below 8.5. A lot of shared hosting runs on cPanel.

The PEAR library present on the server. PEAR ships with PHP on most distributions and in Docker images, so its executable file is usually on disk even if nobody uses it.

If your site meets all three conditions, it is in the highest risk group and should be updated today. If it misses one of them, the flaw still allows including files from disk, so the update is mandatory anyway. The conditions only tell you how close to the worst case you are.

Affected versions and patch numbers

A fix was released for every branch that still receives security patches. If your site runs an older line, an update within the same branch is enough, no jump to 7.1 required.

Branch	Vulnerable versions	Patched version
7.1	7.1.0, 7.1.1	7.1.2
7.0	7.0.0 to 7.0.5	7.0.6
6.9	all	6.9.9
6.8	all	6.8.10
6.7	all	6.7.9
6.6	all	6.6.9
6.5	all	6.5.12
6.4	all	6.4.12
6.3	all	6.3.12
6.2	all	6.2.13
6.1	all	6.1.14
6.0	all	6.0.16
5.x	all	5.0.29 and equivalents for 5.1 to 5.9
4.7 to 4.9	all	4.7.37 and equivalents

Versions older than 4.7 no longer receive any fixes. A site on such a WordPress has far more unpatched holes than this one and needs a migration, not an update.

How to check your site in two minutes

Three checks, most important first.

WordPress version. In the dashboard go to Dashboard -> Updates. If you see 7.1.2 or one of the versions from the table above offered as an update, the site is vulnerable. With WP-CLI:

wp core version
wp core check-update

Theme structure. Check whether the active theme or its parent has a top-level subdirectory starting with page-:

ls -d wp-content/themes/*/page-*/ 2>/dev/null

If the command prints anything, you meet the first of the three conditions.

PHP setting. Check the state of register_argc_argv in the configuration your site actually runs on:

php -r 'var_dump((bool) ini_get("register_argc_argv"));'

A result of bool(true) means you meet the second condition. Note that the PHP binary in your SSH shell is often a different one than the version serving the site. A more reliable answer comes from Tools -> Site Health -> Info -> Server in the dashboard, or a temporary file calling phpinfo() that you delete right after checking.

How to update

Automatically. By default WordPress installs security and minor releases on its own. If you never changed that behaviour, your site is most likely already on 7.1.2. Confirm in Dashboard -> Updates or in the email WordPress sends after every automatic update.

Manually from the dashboard. Dashboard -> Updates -> Update Now. This release contains a single fix and no API changes, so the risk of breaking plugins is minimal. A backup before updating is still a good habit.

With WP-CLI. On a single site:

wp core update
wp core version

If you run a dozen installs on one account, a loop over the directories does the job in a minute:

for d in /home/user/domains/*/public_html; do
  echo "== $d"
  wp --path="$d" core update --minor
done

The --minor flag updates within the current branch. A site on 6.9.8 moves to 6.9.9 rather than 7.1.2, which closes the hole without testing a major upgrade.

If you disabled automatic updates. Check wp-config.php for a line like define('WP_AUTO_UPDATE_CORE', false); or define('AUTOMATIC_UPDATER_DISABLED', true);. That setting only makes sense when someone updates the site by hand on a regular basis. Otherwise set the value to 'minor', as we advised around the 7.0 release. Major versions will wait for your decision, while security patches install themselves, usually within hours of publication.

If you can't update right away

The official announcement offers no workaround and we won't propose one either, because every workaround is worse than the update itself. A few things do reduce exposure while the update waits for a maintenance window.

• WAF rules. Wordfence, Patchstack and most hosting firewalls published rules blocking the known attack patterns within a day of the release. Check that your firewall has current signatures.
• Disabling register_argc_argv. In .user.ini or in your hosting panel set register_argc_argv = Off. WordPress does not need this setting. It cuts off the best-known chain leading to code execution, but it does not remove the flaw itself.
• Don't rename directories in the theme. The page-templates directory is there so the theme can find its page templates. Renaming it breaks the layout of your subpages and does not fully close the hole.

These steps buy hours, not weeks. The update remains the only fix.

How to check whether someone already tried

At the time of writing there are no public reports of attacks on production sites. The flaw is simple, publicly documented and affects a huge number of installs, though, so bots scanning the internet for it are a matter of days, not weeks. It is worth looking at the logs.

In the web server access log, look for requests to pages that contain directory escape sequences in the URL, either plain ../ or encoded as %2e%2e. On hosting with Apache or nginx:

grep -Ei '(\.\./|%2e%2e)' ~/logs/access.log | tail -n 50

Empty output is good news. Hits from the last few days mean someone tried, which does not necessarily mean they succeeded. In that case also check:

• new or modified .php files in wp-content/uploads, where PHP code has no business being,
• unknown administrator accounts under Users,
• changes to wp-config.php, .htaccess and theme files in recent days, via find . -newermt '2026-09-20' -name '*.php',
• cron jobs and plugins you did not install.

If anything on that list checks out, treat the site as compromised. Restore it from a backup taken before September 20, update core and change every password, including the database password and the keys in wp-config.php. The full post-incident hardening procedure is in our WordPress security checklist.

The fifth security release since July

This is the fifth WordPress security patch since July 2026. Five days earlier, on September 17, 7.1.1 shipped with eleven security fixes and dozens of bug fixes. The pace is higher than in previous years and there is no reason to expect it to slow down. Two takeaways. First, automatic updates within a branch should be enabled on every site that has no dedicated administrator. Second, the PHP version matters here too, because the defaults of newer PHP releases and newer hosting panels are safer. We covered which PHP version to pick two weeks ago.

Sources

• WordPress 7.1.2 Release, the official release announcement.
• GHSA-7hp8-65ch-5whp, the security advisory with the list of affected and patched versions and the CVSS vector.
• Patchstack: WordPress 7.1.2 Security Release, technical analysis and exploitation conditions.
• Help Net Security: CVE-2026-87902, a summary for administrators.

What we do for mDiv clients

A security release rated 9.2 does not wait for the next monthly review. Under our care plans, core security releases go out off the regular cycle, within hours of publication, after checking that they don't change plugin behaviour. A backup on a separate server provides a restore point in case something goes wrong. And if your current host keeps you on an old PHP with defaults from years ago, migrating to mDiv is free.

If you run a site on one of the themes listed above and don't know which WordPress version you are on, get in touch. The check takes a few minutes. A compromised site usually costs days.