WordPress patched every branch twice in five days: 7.1.2 fixes an include flaw scored 9.2 and 8.1

Fifty releases in five days

WordPress shipped 25 core releases on 17 September 2026 and 25 more on 22 September 2026. Counted from the WordPress.org release archive, that is 50 versions of WordPress in five days, and it means every branch still eligible for a security fix, all the way back to 4.7, was patched twice inside a working week. The 4.7 branch, which has not been actively supported for years, went from 4.7.35 to 4.7.36 to 4.7.37 in the space of six weeks.

The second of the two is the one to read carefully. WordPress 7.1.2 carries a single security fix and nothing else. It is tracked as CVE-2026-87902, and WordPress rates it critical at CVSS 4.0 9.2. The release post, written by John Blackbourn, describes it in one sentence: an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories, and if the preconditions for both the server environment and the active theme are met, that can lead to remote code execution.

What that does not establish. Fifty releases is not fifty flaws. It is two flaws, each backported across the same 25 branches. It does not establish that either flaw has been used: the CISA-ADP enrichment on CVE-2026-87902, timestamped 22 September 2026, records exploitation as none and automatable as no, with technical impact total, and neither this CVE nor the one fixed five days earlier appears in CISA's Known Exploited Vulnerabilities catalogue, version 2026.09.23, which holds 1,721 entries. Nor does it establish that any particular site was exposed, because this flaw needs two separate preconditions to hold at the same time.

pk-sharma.com covered the first of the two releases in WordPress fixed Comment2Shell in 25 releases on one day. This is a different flaw, of a different class, reached by a different route, and the control that mattered most in that piece does nothing about this one.

What the flaw is, at a defender's level

The advisory, GHSA-7hp8-65ch-5whp, classifies the flaw as CWE-98, improper control of filename for an include or require statement in a PHP program. In plain terms: WordPress decides which template file to load for a page, and an unauthenticated request can steer that decision at a file outside the theme directories that WordPress meant to confine it to. The function named on the record is get_page_template().

The advisory states two preconditions, and both must hold.

The two preconditions, as stated in GHSA-7hp8-65ch-5whp, published 22 September 2026

Precondition	What the advisory says	Named examples
The active theme	The active parent or child theme contains a top level directory whose name starts with `page-`, for example `page-templates`	The legacy Twenty Twelve and Twenty Fourteen themes, and the third party themes Neve, Hestia and Sydney
The server environment	A chosen local `.php` target file exists on the server and is readable by the web server account	The `pearcmd.php` route when `register_argc_argv` is set to On; the official php image for Docker; the default cPanel configuration when PHP earlier than 8.5 is in use

Two figures give a sense of the population, and neither is a count of vulnerable sites. The WordPress.org theme directory reports 200,000 active installations of Neve, 80,000 of Sydney, 70,000 of Hestia, 50,000 of Twenty Twelve and 50,000 of Twenty Fourteen: 450,000 in total for the five themes the advisory names, on the directory's own rounded figures. Separately, WordPress.org's PHP version statistics show 3.245 per cent of reporting installations on PHP 8.5 and 0.012 per cent on 8.6, so 96.74 per cent are on a PHP earlier than 8.5, which is the version boundary the advisory draws for default cPanel.

Neither number tells you how many sites are exposed, because exposure needs a theme condition and a server condition together, and the advisory attaches the PHP version boundary specifically to cPanel rather than to hosting in general. What they do tell you is that the preconditions are ordinary rather than exotic. This briefing does not reproduce a traversal string or any exploit code, and none is needed to act on the above.

The same flaw scores 9.2 and 8.1, and the gap is the interesting part

WordPress publishes the flaw as critical, CVSS 4.0 base score 9.2, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The NVD record carries no version 4 score at all. It carries one metric, CVSS 3.1 base score 8.1, High, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, and its source is 134c704f-9b21-4f2e-91b3-4a467353bcc0, which is CISA-ADP rather than the vendor. The CNA of record on the CVE is HackerOne, and it published no score of its own in the NVD entry.

The gap is not a disagreement about the facts. It is an artefact of the instrument. CVSS version 4.0 added an Attack Requirements metric for conditions outside the attacker's control that must happen to be true of the deployment. WordPress set Attack Complexity to Low and Attack Requirements to Present, which is exactly what the two preconditions are. CVSS version 3.1 has no Attack Requirements metric, so a scorer with the same facts has only one place to put those preconditions: Attack Complexity, raised to High, which drags the score down. Same flaw, same preconditions, two instruments, a difference of 1.1 points and a severity band.

What each published score establishes, and what it does not, from the GHSA advisory and the NVD record for CVE-2026-87902

Score on the record	Who assigned it	What it does not settle
CVSS 4.0 9.2, Critical	WordPress, on GHSA-7hp8-65ch-5whp	Whether the two preconditions hold anywhere in your estate
CVSS 3.1 8.1, High	CISA-ADP, in the NVD record	Nothing about likelihood: version 3.1 has no metric for deployment preconditions, so they fall into Attack Complexity
No CVSS at all	HackerOne, the assigning CNA	Why the CNA published no score of its own; the NVD record simply does not carry one

Read or write is the wrong question

"Path traversal" is a comforting label, and the comfort usually comes from an assumption that traversal means reading files. Precision matters here, because the class of the flaw tells you more than its name does.

This is not a write. Nothing in the flaw causes WordPress to create or modify a file on disk; the advisory describes a chosen file that already exists and is already readable by the web server account. That is also why the control that mattered in the Comment2Shell piece is irrelevant here.

It is also not a read in the sense most people mean. The classification is CWE-98, an include, and the advisory's own wording is that resolution can be made to include a chosen readable local .php file. In PHP, including a file runs it. The path is the input; the outcome is execution of whatever that file does, which is why a helper such as pearcmd.php turns the flaw into remote code execution while an arbitrary inert file would not.

The advisory does not state whether a successful include exposes the contents of any file, and it does not mention wp-config.php at all. Treat file disclosure as unestablished in both directions rather than assuming either way. What the advisory does commit to is impact: high confidentiality, integrity and availability impact on the vulnerable system, and none on subsequent systems.

Two releases, five days apart, and what changed between them

WordPress 7.1 opened a new major branch on 19 August 2026, taking the number of branches eligible for security fixes to 25. WordPress 7.1.1 followed 29 days later on 17 September, and 7.1.2 came 5 days after that on 22 September. A branch barely a month old has already had two security releases.

The two releases are not the same shape. WordPress 7.1.1 was a combined maintenance and security release: 17 core bug fixes, 19 block editor fixes and 11 security fixes, led by a team of four. WordPress 7.1.2 is a security release with one fix and no maintenance at all, led by John Blackbourn alone. Both were backported to every branch through to 4.7, and the release archive shows all 25 versions dated the same day in both cases, even though the 7.1.1 post said at publication that its backports were in progress and would ship as they became ready.

Something else changed between the two posts, and it is a change for the better. The 7.1.1 post names no CVE anywhere on the page: the identifiers for those 11 fixes arrived later, through Patchstack and the NVD. The 7.1.2 post names CVE-2026-87902 and GHSA-7hp8-65ch-5whp directly, and links a full GitHub security advisory with a CVSS version 4 vector, affected ranges for all 25 branches and the preconditions written out. That is a materially better artefact for anyone who has to write a change record.

It goes the other way on code provenance. The 7.1.1 post linked its Trac milestone so a reader could see the tickets. The 7.1.2 post links no Trac ticket and names no changeset. Core Trac returned HTTP 403 to our requests, so we could not check the 7.1.2 milestone independently; the point stands only that the release post itself names none.

One more detail is worth recording for anyone tracking who is finding these. Two of the 11 fixes in 7.1.1 are credited to Anthropic: an authenticated path traversal in the WP REST Templates Controller, and a Contributor-and-above arbitrary post overwrite. So September 2026 brought WordPress core two separate path traversals inside five days, one requiring authentication and one requiring none.

Stated and not stated

From the WordPress 7.1.2 release post, GHSA-7hp8-65ch-5whp, the NVD record and the CISA KEV catalogue version 2026.09.23

Question	Stated	Not stated
How many branches got a fix?	25, from 4.7.37 to 7.1.2, all dated 22 September 2026
Is it read or write?	An include of an existing readable PHP file, CWE-98	Whether a successful include discloses any file contents, including wp-config.php
Was it exploited before the fix?	CISA-ADP records exploitation as none; not in KEV	Whether anyone attempted it before 22 September 2026
Are there indicators to search for?		The advisory gives no indicator of compromise, no log signature and no file artefact
Which themes?	Twenty Twelve, Twenty Fourteen, Neve, Hestia and Sydney are named	A complete list of themes with a top level page- directory
Who found it?	Robert Ressl, responsibly disclosed	The report date, and how long the fix took
Do automatic updates cover it?	The release post states that sites supporting automatic background updates will begin the update automatically	Any figure for how many sites have them switched off

The missing report date is the one gap worth flagging to a board. For the earlier flaw we could compute the interval, nine days from report on 8 September to fix on 17 September, because the researcher published his timeline. For CVE-2026-87902, neither the release post nor the advisory gives a report date, so the time to fix cannot be computed. Do not let anyone put a number on it.

What automatic updates cover, and who they miss

Automatic background updates were introduced in WordPress 3.7. WordPress's own administration documentation states that before WordPress 5.6, every site had automatic updates enabled for minor core releases and translation files only by default, and that from 5.6 new installations have automatic updates enabled for both minor and major core releases by default, unless WordPress detects a version control checkout.

Both September releases are minor core updates within their own branch: 7.1.1 and 7.1.2 on the 7.1 branch, 6.9.8 and 6.9.9 on the 6.9 branch, and so on down to 4.7.36 and 4.7.37. That means the same default covers both, and it means a site that received the 17 September fix without anyone touching it will have received the 22 September fix the same way. The exception is the version control checkout: a site deployed from a repository gets no automatic core update, and those are frequently the agency-built sites nobody is watching.

A site owner who switched them off has three things to undo, and needs to know which one was used.

• AUTOMATIC_UPDATER_DISABLED set to true disables all automatic updates. Remove it, or accept that every update is now a manual task with an owner and a date.
• WP_AUTO_UPDATE_CORE set to false disables development, minor and major core updates. Setting it to 'minor' restores exactly the behaviour that ships these security fixes while leaving major upgrades under human control, which is the setting most estates actually want.
• A filter in a theme or plugin. add_filter( 'auto_update_core', '__return_true' ); re-enables all core updates and add_filter( 'allow_minor_auto_core_updates', '__return_true' ); re-enables minor ones specifically.

If policy forbids re-enabling any of it, the obligation does not go away: someone must install the fixed release for each branch by hand, record the date, and be able to show the version afterwards. That is a named job, not a setting.

# The version each site reports right now
wp core version

# The active theme, and whether it holds a top level page- directory
wp theme list --status=active --field=name
ls -d wp-content/themes/*/page-*/ 2>/dev/null

# Whether register_argc_argv is on. Note this reports the command line
# configuration, which can differ from the web request handler's.
php -i | grep -i register_argc_argv

What to do, in order

The question that exposes the gap

WordPress did the hard part well. Two flaws, two fixes, every branch back to 4.7 patched inside five days, and an update mechanism that carried both to most of the world without anyone filing a ticket. There is very little to criticise in the response.

The gap is on the other side. If your answer on 17 September was that automatic updates had handled it, you have now been asked the same question twice in five days, and the branch in question is five weeks old. So, for each WordPress site your organisation owns or pays for: can you name the version it is running today, the date the update ran, and the person who would have told you if it had not?