← All posts

WordPress vulnerabilities in 2026, CVE-2026-87902, wp2shell and the safe version per branch

CentralCSP Team ·

Last update:

WordPress 7.1.2 shipped on 22 September 2026 with a single fix, and attackers were sending requests for it the same day. Three days later CISA added the bug, CVE-2026-87902, to its catalog of known exploited vulnerabilities. It is the second WordPress core flaw this year to go from patch to active exploitation within days, after wp2shell in July.

This page covers CVE-2026-87902 first: what it is, which versions are affected, the fixed version for every branch, and the conditions that turn it into code execution. Then it lists every WordPress core security release of 2026, the plugin flaws attackers exploited at scale, and how to check which version a site really runs. We update it as new advisories land.

The WordPress vulnerability of 2026, CVE-2026-87902

CVE-2026-87902 is an unauthenticated path traversal in page-template resolution, in wp-includes/template.php. WordPress builds a list of candidate template files from the requested page, and the candidate built from the pagename value was not validated like the others. An attacker can make WordPress include a readable .php file from outside the active theme directories. Robert Ressl reported it.

CVECVE-2026-87902
TypePath traversal leading to conditional remote code execution (CWE-98)
AuthenticationNone
SeverityCritical, 9.2 under CVSS 4.0 as scored by Patchstack
AffectedWordPress 4.7.0 to 7.1.1
Fixed7.1.2, released 22 September 2026, with fixes for every branch back to 4.7
ExploitedYes. Added to the CISA KEV catalog on 25 September 2026

Which version is safe for each branch

WordPress released the fix for every branch from 4.7 up. Only the latest version is actively supported, but these are the first safe releases if you are on an older line:

BranchFixed inBranchFixed in
7.17.1.25.85.8.17
7.07.0.65.75.7.19
6.96.9.95.65.6.21
6.86.8.105.55.5.22
6.76.7.95.45.4.23
6.66.6.95.35.3.25
6.56.5.125.25.2.28
6.46.4.125.15.1.26
6.36.3.125.05.0.29
6.26.2.134.94.9.33
6.16.1.144.84.8.32
6.06.0.164.74.7.37
5.95.9.184.6 and olderNo fix, unsupported

When it becomes remote code execution

The traversal alone lets an attacker include a .php file that already exists on the server. According to Patchstack's analysis, turning that into code execution needs three conditions at once:

  1. The active theme has a top-level directory whose name starts with page-.
  2. PHP runs with register_argc_argv enabled. It is on in the official Docker images and in cPanel with PHP below 8.5.
  3. A usable .php file is readable on the server, typically PEAR's pearcmd.php.

The exploitation reported so far follows this path. The Hacker News, citing Patchstack and Previdian, describes attackers using pearcmd.php to write PHP files to /tmp and /var/tmp within hours of the release.

Am I affected?

  • Your WordPress version is between 4.7.0 and 7.1.1, and not one of the fixed releases in the table: you are affected by the traversal. Update.
  • You also match the three conditions above: an attacker can run code on your server. Treat the site as possibly compromised if it stayed unpatched after 22 September, and look for unexpected PHP files in /tmp, /var/tmp, and your uploads directory.
  • You run 4.6 or older: there is no fix for your line. Upgrade to a supported version.

What to do

  1. Update to 7.1.2, or to the fixed release of your branch. WordPress installs minor releases like this one automatically by default, so check that the update actually landed: a host or a plugin can turn background updates off.
  2. Check the three conditions even after updating, because they also matter for the next include bug. Disable register_argc_argv if nothing on the server needs it, and remove PEAR if you do not use it.
  3. Look for traces if the site was exposed: new PHP files in temporary and upload directories, new admin accounts, and requests with pagename values containing ../ in your access logs.

Every WordPress core security release of 2026

DateReleaseMain issueSeverityFixed in
10 to 11 March6.9.2, 6.9.3, 6.9.4Ten fixes, including a blind SSRF, stored XSS, an authorization bypass, a PclZip path traversal and an XXE in getID3. 6.9.2 broke some sites, and 6.9.4 completed the fixes the next dayMixed6.9.4
17 July7.0.2wp2shell, CVE-2026-63030 and CVE-2026-60137, an unauthenticated chain from REST API batch-route confusion and SQL injection to code execution. Exploited within days, in CISA KEV since 21 JulyCritical, 9.8 for CVE-2026-630307.0.2, 6.9.5, 6.8.6 (SQL injection only)
6 August7.0.3Twelve fixes. The headline is CVE-2026-64638, an unauthenticated reflected XSS on the login screen that can lead to PHP code executionHigh, 8.9 for CVE-2026-646387.0.3, every branch to 4.7.34
12 August7.0.4CVE-2026-65640, code execution by an Author or above through a malicious upload on sites using Imagick and GhostscriptHigh7.0.4, every branch to 4.7.35
19 August7.1Major release
17 September7.1.1Eleven fixes, including an unauthenticated stored XSS through paragraph formatting (subject to comment approval) and an authenticated path traversal in the REST API templates controllerMixed7.1.1, 7.0.5, every branch to 4.7.36
22 September7.1.2CVE-2026-87902, the page-template path traversal above. In CISA KEV since 25 SeptemberCritical7.1.2, every branch to 4.7.37

wp2shell is the other release that deserves its own note. It affected 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1 in their default configuration, and the WordPress team forced the update through the auto-update system on sites running affected versions. If your 7.0 site was frozen on 7.0.1 in July, it was exposed to a chain that needed no account and no plugin.

The plugin flaws attackers exploited in 2026

Core gets the headlines, but most compromised WordPress sites in 2026 came through plugins. Three critical, unauthenticated flaws were exploited at scale:

PluginCVEIssueFixed in
Everest Forms ProCVE-2026-3300Form values from the Complex Calculation feature reach eval(), so a crafted submission runs PHP. Wordfence reports exploitation from mid-April1.9.13
WooCommerce Wholesale Lead CaptureCVE-2026-27540Arbitrary file upload in an AJAX action, used to plant web shells. Over 100,000 blocked attempts since June according to Wordfence2.0.3.2
Elementor ProCVE-2026-32475A file-upload validation flaw in forms with a File Upload field. Exploitation began the day 4.2.2 shipped, 19 August4.2.2

All three were exploited after a patch existed. The gap between a fix and an update is where sites get compromised, for plugins and core alike.

How to check which WordPress version a site runs

You need the version to read the tables above. On a site you administer, it is in Dashboard > Updates. From the outside, a WordPress page usually exposes it in the generator meta tag or in the ver= query string on core scripts and stylesheets, although many sites remove both.

The free Technology Checker reads it for you. Enter the URL and it lists WordPress with the version the page exposes, whether that version is current, and the known CVEs affecting it, along with the JavaScript libraries the page loads. WordPress ships its own jQuery, so check that row too: old jQuery copies are a frequent finding on WordPress sites.

Read the result for what it is. The checker sees the version a public page exposes. It cannot see your server configuration, so for CVE-2026-87902 it tells you whether your version is affected, and the three conditions above tell you whether the bug reaches code execution on your server. If the site hides its version, the checker reports WordPress without one, and the dashboard is the place to look. The broader method is in What technology is this website using.

Get alerted when the next one lands

A check answers for today. WordPress shipped core security releases in March, July, August and September 2026, and two of the plugin flaws above were exploited from the day of the fix, so the useful question is how fast you learn that a version you run became vulnerable.

CentralCSP builds an inventory of the scripts your visitors' browsers actually run, on every page, and maps them to technologies and versions. When a new CVE affects a version in that inventory, an alert fires with the version and the advisory. The Technologies feature shows each library with its status and where it loads, the supply-chain page has the tour, and Build a script inventory with CSP hash reporting explains how the inventory is built. Start free with CentralCSP to see your own sites.

FAQ

Is WordPress 7.1.1 vulnerable?

Yes. WordPress 7.1.1 is affected by CVE-2026-87902, the unauthenticated page-template path traversal fixed in 7.1.2 on 22 September 2026. CISA lists it as exploited in the wild. Update to 7.1.2, or to the fixed release of your branch, such as 7.0.6 or 6.9.9.

Which WordPress versions are affected by CVE-2026-87902?

Every release from 4.7.0 to 7.1.1, except the fixed releases published on 22 September 2026 for each branch (7.0.6, 6.9.9, 6.8.10 and down to 4.7.37). WordPress 4.6 and older are unsupported and get no fix.

Does WordPress update itself for security fixes?

By default, WordPress installs minor releases such as 7.1.2 automatically through background updates. A host, a plugin, or a constant in wp-config.php can turn that off, so confirm the version in Dashboard > Updates rather than assuming the update ran.

What is wp2shell?

wp2shell is the name given to two WordPress core flaws fixed on 17 July 2026, CVE-2026-63030 and CVE-2026-60137. Chained, they let an unauthenticated attacker reach the database and run code on WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1. WordPress forced the 7.0.2 and 6.9.5 updates through auto-updates, and CISA added CVE-2026-63030 to its exploited catalog on 21 July.

How can I check the WordPress version of a site I do not manage?

Look for the generator meta tag or the ver= parameter on core assets, or enter the URL in the Technology Checker, which reports the version the page exposes with its known CVEs. Only check sites you own or are authorised to assess.

Sources