WordPress 7.1.2: a critical core vulnerability attackers are already exploiting

The WordPress 7.1.2 vulnerability CVE-2026-87902 is a critical flaw in WordPress core, fixed on 22 September 2026 in version 7.1.2. The attacker does not need to log in. A crafted request can make page template resolution load a different PHP file on the server, and when the server and the theme meet certain conditions, run the attacker's own code. Versions 4.7.0 to 7.1.1 are affected, and the fix was released for every branch back to 4.7. Patchstack has already recorded active exploitation, including files written to disk. Update today.

This article is an action plan for site owners and administrators: what the flaw does, how to find your version, how to update without breaking the site, how to look for traces of an attack and what to do if you cannot update right away. General hardening advice is in our 10-point WordPress security checklist; here we deal with this one flaw only.

What the WordPress 7.1.2 vulnerability CVE-2026-87902 is

It is a path traversal in page template resolution that leads to local file inclusion and, under certain conditions, to remote code execution (RCE).

When WordPress renders a page, the get_page_template() function builds a list of candidate template files. According to Patchstack's technical analysis, one of those candidates was built from the pagename parameter, which comes straight from the request, and unlike the neighbouring code branch it never went through the validate_file() check. An encoded parent-directory sequence therefore made it into the file path, and WordPress could include a PHP file outside the active theme directories.

The official security advisory GHSA-7hp8-65ch-5whp rates the flaw as critical with a CVSS 4.0 score of 9.2 and classifies it as CWE-98. For the attacker to reach code execution, two conditions must hold:

• The theme has a directory starting with page-: the active parent or child theme contains a top-level directory whose name starts with page-, such as page-templates. The advisory names the older default themes Twenty Twelve and Twenty Fourteen and the popular third-party themes Neve, Hestia and Sydney.
• A suitable PHP file exists on the server: attackers use the well-known pearcmd.php file from the PEAR package, which can be abused when PHP has register_argc_argv enabled. According to the advisory this applies to the official php Docker image and to the default cPanel configuration with PHP older than 8.5.

If the theme meets the first condition, unauthenticated file inclusion works. Whether the attacker also runs their own code depends on the server. Patchstack therefore recommends treating the flaw as critical until you have checked your own environment. The fix in 7.1.2 has two parts: it adds the missing validate_file() check, and it introduces a new check requiring every resolved template path to sit inside an allowed theme directory. According to Patchstack, the security team treated this as a whole class of problems rather than a single bug.

Who the WordPress 7.1.2 vulnerability affects and which versions are fixed

Every site on WordPress 4.7.0 to 7.1.1 that has not yet received the fixed release of its branch is affected. WordPress shipped the fix for every branch that still receives security fixes, which means back to 4.7. An older site can therefore take the fix without a major version jump. According to the official 7.1.2 release announcement, however, only the most recent version is actively supported.

Branch	Vulnerable versions	Fixed version
7.1	7.1.0 to 7.1.1	7.1.2
7.0	7.0.0 to 7.0.5	7.0.6
6.9	6.9.0 to 6.9.8	6.9.9
6.8	6.8.0 to 6.8.9	6.8.10
6.7	6.7.0 to 6.7.8	6.7.9
6.6	6.6.0 to 6.6.8	6.6.9
6.5	6.5.0 to 6.5.11	6.5.12
4.7	4.7.0 to 4.7.36	4.7.37

You can find your version in a minute:

• In the admin: Dashboard > Updates. The page shows the current version and offers an update if one is available.
• With WP-CLI: the command wp core version prints the core version.
• With several sites: check all of them, including old microsites, sites on subdomains and test copies on the hosting. An automated scanner goes through them just like the main site.

If the site has automatic background updates enabled, the WordPress announcement says the update will start on its own. Do not take that for granted and check the version. Someone may have switched automatic updates off in the past, and that usually only comes to light during an incident like this one.

How to update today without breaking the site

Updating core to a fixed release is the only real fix; everything else only reduces the risk for a while. According to Patchstack, 7.1.2 is a security-only release with a single fix, so the risk of it breaking the site is lower than with a major update. Still, work in this order:

1. Backup: back up the database and the files before updating. If you do not have a tested routine, use our guide to backing up a WordPress site with the 3-2-1 rule.
2. Update: in the admin go to Dashboard > Updates > Update Now, or run wp core update in WP-CLI. On an older branch you can install the fixed release of that same branch directly, for example wp core update --version=6.8.10, and plan the move to the latest version separately.
3. Check the version: after the update, look again to confirm the site really runs 7.1.2 or the fixed release of its branch.
4. Functional test: go through the key parts of the site: the contact form, login, and the cart and checkout if it is an online store.

For an online store or a site with many plugins, the safer route goes through a test copy, which we describe in the article on WordPress updates with staging and rollback. With a flaw that attackers are already actively probing, however, do not delay the production update by days. If something breaks after the update, see our guide on what to do when the site stops working after a WordPress update.

How to find out whether attackers have already tried your site

Attacks began on the day the fix was released, so updating is not enough; you also need to look at the logs and the server. According to Patchstack's ongoing monitoring, its firewall caught the first attempts on 22 September 2026, the day 7.1.2 came out, and on that same day also the first attempt to write a file to disk through pearcmd.php. Patchstack says the attackers built their payloads from the diff of the fix. Since 23 September, public scanning tooling has been in circulation, including a named template for the Nuclei scanner, so anyone can now try the flaw, not just a small group of attackers.

According to Patchstack, the attack runs in three stages: checking whether the file inclusion works (using harmless core files), checking whether pearcmd.php is reachable, and writing a PHP file to disk. In your access logs, look for these signals:

• a pagename parameter containing %2e%2e or %252e%252e, in the URL or in a POST body,
• a pagename value starting with templates%2f or the name of another page- directory,
• the pagename and page_id parameters together in one request to the site root or to /index.php,
• any occurrence of the strings pearcmd, +config-show or +config-create.

On the server, check the /tmp and /var/tmp directories. According to Patchstack, unexpected .php files there mean the write succeeded, and the server should be treated as compromised, not merely scanned. The second signal is in the logs: a 200 response carrying OPML or RSS content on a normal page URL means the file inclusion ran on your server. On shared hosting you often cannot see these directories; in that case ask your hosting provider to check them.

If you find such traces, updating alone is not enough. Change the administrator passwords and the hosting credentials, regenerate the security keys in wp-config.php, review the list of users with the administrator role and consider restoring from a backup taken before the attack.

What to do if you cannot update right away

You can reduce the risk temporarily, but none of this replaces the update. These steps only bridge the gap until the update is ready:

• Look inside the theme directory: open wp-content/themes and, in both the active theme and its parent theme, look for a top-level directory whose name starts with page-. If there is one, the first exploitation condition is met.
• Check register_argc_argv: you will find the value in the phpinfo() output for the web PHP, or ask your hosting provider. According to Patchstack, turning it off does not fix the file inclusion, but it breaks the pearcmd chain that turns an information leak into code execution.
• A firewall (WAF) rule: reject requests where the pagename parameter contains a parent-directory sequence. A real page slug never contains one, so according to Patchstack this does not affect normal traffic.
• Do not rely on blocking IP addresses: Patchstack sees attacks from a few hundred addresses, and most requests pose as an ordinary browser.

In practice: what this flaw shows about website maintenance

A core flaw also hits sites whose plugins are fine, so maintenance cannot rest on plugin checks alone. With small business websites we regularly see that the sites people forget most are the ones that never change: a campaign microsite, an old site on a subdomain, a test copy on the hosting. Those are exactly the ones that run for years on an old branch with nobody watching. With this flaw, the structure of the theme also matters, and an ordinary list of vulnerable plugins will not show it.

The second lesson is speed. When attackers probe a flaw on the day the fix is released, a monthly update cycle is not enough for security releases. A controlled staging workflow makes sense for major versions, but a core security release belongs on the site the same day. How this fits into a full year of maintenance is covered in our complete guide to WordPress website maintenance.

How we handle it at Denva: when we take a site into care and support, we first look at versions, plugins, backups, hosting and the state of security. During regular care we keep track of known vulnerabilities, and after every update we check that the site really works, for example that the form sends and the checkout loads. We also look after sites built by someone else.

When you can handle it yourself and when to bring us in

You can handle it yourself if:

• you run one site on a current branch with automatic core updates enabled,
• you can check the version and make a backup you have restored from before,
• your hosting provider will send you access logs on request and check the /tmp directories.

It is worth bringing us in if:

• your logs show pagename with encoded sequences or the string pearcmd,
• the site runs on an old branch or has a customised theme with a page- directory,
• you manage several sites and do not know which versions they run,
• you have no backup you could reliably restore the site from.

Conclusion

If your WordPress is not on 7.1.2 or on the fixed release of its branch, update today and then look at the logs and the /tmp directories. The flaw is rated CVSS 4.0 9.2, a fix exists for every branch from 4.7, and according to Patchstack attacks have been running since the day of the release. A theme with a page- directory and register_argc_argv turned on is what turns file inclusion into code execution, so check both conditions even after updating. If you are not sure what you found in the logs, write to us and we will look at it with you.

FAQ

Frequently asked questions.

Is my site safe if automatic updates are enabled?

Probably, but check it. According to the WordPress announcement, sites with automatic background updates start the update on their own. On the Updates page in the admin, confirm that the site runs 7.1.2 or the fixed release of its branch.

Do I have to move to WordPress 7.1 if I run an older version?

Not for this flaw. WordPress released the fix for every branch back to 4.7, for example 6.8.10 or 4.7.37. Only the most recent version is actively supported, though, so plan the upgrade.

How do I find out whether my theme meets the exploitation condition?

Look inside the active theme and its parent theme in wp-content/themes. If the top level contains a directory whose name starts with page-, such as page-templates, the condition is met. It does not replace the update.

What if I find requests containing pearcmd in my logs?

It means an attacker tried the chain that leads to code execution. Check the /tmp and /var/tmp directories for unexpected .php files. If they are there, treat the server as compromised, change credentials and consider restoring from a backup.

Is a firewall or security plugin enough instead of updating?

No. According to Patchstack, a rule that rejects parent-directory sequences in the pagename parameter is an effective stopgap. The only real fix is updating core to a fixed release.