In short and in plain language
There was an update for a serious gap in WordPress. Many older versions got a fix, too.
The article explains what older versions still get and what not. You cannot rely on this. It also matters that the update really reaches your site.
If you stay on an old version, you should plan the switch.
After each security update, we check whether it has reached your sites. We plan the switch to a supported version with you.
On 22 September 2026 WordPress 7.1.2 shipped with a fix for a flaw the project itself rates as critical (WordPress.org). On the same day, sites on much older versions received a point release too: 7.0.6, 6.9.9, 6.8.10 and so on all the way down to 4.7.37, 25 branches in total including 7.1 (Advisory GHSA-7hp8-65ch-5whp). Anyone running a shop or company site on WordPress 6.4 or 5.9 was therefore protected, provided the update actually arrived. Behind this lies a branch policy that is rarely explained: officially, only the most recent version is actively supported. Everything below it receives security fixes as a courtesy, with no commitment for the next flaw, and branches below 4.7 have received nothing at all since July 2025 (WordPress Security Team). This article explains what older branches get today, why a point update on the old branch is enough for now, where that reasoning ends and when the move to 7.x belongs in the maintenance plan.
Key takeaways
- WordPress 7.1.2 of 22 September 2026 closed a critical flaw with a CVSS score of 9.2 (Advisory GHSA-7hp8-65ch-5whp). 25 branches (Advisory GHSA-7hp8-65ch-5whp) from 7.1 down to 4.7 were patched, 24 of them through backports.
- Officially, only the most recent WordPress version is actively supported (WordPress.org). Backports to older branches are a courtesy of the security team, with no commitment for the next flaw and no fixed schedule.
- Branches below 4.7 no longer receive security fixes. The last release for 4.6 was 4.6.30 on 17 July 2025 (WordPress.org Releases); the end was announced in June 2025, barely a month earlier (WordPress Security Team).
- The branch also caps PHP: WordPress 4.7 is compatible with PHP 7.1 (Make WordPress Core) at most, and PHP 7.1 has received no security updates since 1 December 2019 (The PHP Group).
- Backports reach a site through automatic minor updates. Anyone who switches them off has to apply every security release by hand and then compare the installed version with the patched version of their branch.
- At the latest when the highest PHP version a branch supports drops out of maintenance, the move belongs in the maintenance plan: for 6.1 to 6.3 that is PHP 8.2, whose security support ends on 31 December 2026 (The PHP Group).
What was backported on 22 September
The flaw fixed by WordPress 7.1.2 sits in page template resolution. According to the release post, an unauthenticated attacker can, under certain conditions, make WordPress include a local PHP file outside the theme directories; if further pre-conditions on the server and the active theme are met, this turns into remote code execution (WordPress.org). The advisory rates the flaw at 9.2 out of 10 on the CVSS scale (Advisory GHSA-7hp8-65ch-5whp) and spells out the pre-conditions: the active theme must contain a directory whose name starts with "page-", which applies among others to the older default themes Twenty Twelve and Twenty Fourteen, and a suitable PHP file must be readable by the web server.
For maintenance purposes, a different paragraph of the release post matters more than the technical description. Under the heading "Backports" it says that the fix was carried over as a courtesy to every branch still eligible for security fixes, currently down to and including 4.7 (WordPress.org). The advisory lists the results: 25 patched versions, from 7.1.2 via 7.0.6, 6.9.9 and 6.8.10 to 4.7.37 (Advisory GHSA-7hp8-65ch-5whp). A site running WordPress 5.4 on 22 September therefore received 5.4.23, not 7.1.2. The branch stays the same; only the third digit of the version number goes up. Features, dependencies and PHP requirements as a rule stay unchanged.
As a courtesy, the security fix was backported to all branches eligible to receive security fixes (currently through 4.7). As a reminder, only the most recent version of WordPress is actively supported.
The second sentence of the quote is the core of this article. Only the most recent version is actively supported (WordPress.org), which at the time of the release meant 7.1. Everything else the fix reached is a voluntary effort by the security team. The security page on WordPress.org also describes the purpose of that effort: older sites are meant to receive critical security fixes through automatic updates (WordPress.org). Two questions follow that every operator of an older branch should be able to answer. Does the update reach my site? And for how much longer will it be delivered?
Three states: supported, backported, retired
From an operator's point of view, a WordPress branch can be in one of three states. The boundaries between them shift with every major version and with every decision of the security team. Branch 7.0 shows how quickly that happens: it was released on 20 May 2026 and, with the release of 7.1 on 19 August 2026 (WordPress.org Releases), stopped being the actively supported branch after only three months. The table shows the situation after the security release of 22 September 2026.
| State | Branches (as of October 2026) | What arrives | What does not arrive |
|---|---|---|---|
| Actively supported | 7.1 only (WordPress.org) | Security fixes, bug fixes and every further point release of the branch | nothing essential, this is the maintained state |
| Backported as a courtesy | 7.0 down to 4.7, 24 branches in total (Advisory GHSA-7hp8-65ch-5whp) | Security fixes, as far as the security team considers them necessary for the branch | as a rule no pure bug fixes, no new features, no commitment for future flaws |
| Retired | 4.6 and older (WordPress Security Team) | nothing; the dashboard shows a notice that cannot be dismissed | every security fix since July 2025 |
The middle row is the largest and the most uncomfortable. It contains installations that are protected today without anyone having promised that protection. A shop on 6.2 is just as protected against the template flaw after the update to 6.2.13 as one on 7.1.2. But it is protected only because the security team carried the effort for this branch once more. Anyone who builds a maintenance plan on this row is planning with a service that a third party can discontinue unilaterally.
Why the line is currently drawn at 4.7
The line is not fixed; it has already been moved up twice. Until the end of November 2022, backports reached all the way down to branch 3.7, whose last release was 3.7.41 on 30 November 2022 (WordPress.org Releases). From December 2022 they only went down to 4.1 (WordPress Security Team). In June 2025 the team then announced that updates for 4.1 to 4.6 would stop in July 2025 (WordPress Security Team). The release archive shows how that ended: the last release for 4.6 was 4.6.30 on 17 July 2025, and for 4.1 it was 4.1.42 on 15 July 2025 (WordPress.org Releases).
The reasoning is in the same announcement and it is matter-of-fact. The effort of keeping old branches alive, together with the tooling for backporting, building, testing and releasing, now outweighed the benefit. Well below 1 percent of sites were still running 4.1 to 4.6 in June 2025 (WordPress Security Team). During a security release the team spent most of the time on backports for a minority of installations (WordPress Security Team), and that effort grows with every major version because one more branch is added.
The line can move again
So branches from 4.7 upwards currently receive fixes, and everything below does not. According to the announcement, sites below 4.7 show a notice in the dashboard that cannot be dismissed; for the final updates of these branches the team announced it would make the notice more prominent and point out that security updates have ended (WordPress Security Team). Anyone who sees such a notice in a client's back end is not looking at a cosmetic issue but at a branch without any maintenance. For the counterpart in other systems, which publish their end of support with a fixed date, see the support deadlines for TYPO3, Drupal and Joomla.
What courtesy means in day-to-day operations
Courtesy sounds harmless, but it has three practical consequences. The first: backports happen only where necessary. For security release 6.9.2 in March 2026 the post said explicitly that the fixes were being carried "where necessary" to all branches down to 4.7 (WordPress.org). If a flaw affects code that an old branch does not contain, no release appears there, and the operator has to work out whether their branch was affected at all.
The second: backports do not necessarily arrive on the same day. For WordPress 6.9.2 of 10 March 2026 the post said the backports were in progress and would ship as they became ready (WordPress.org). According to the release archive, 6.8.4 was the only older branch release on the same day, 6.7.5 to 6.4.8 followed on 11 March, branches 6.3 to 5.3 except 6.0 on 12 March and 5.2.24 to 4.7.32 on 13 March 2026; for branch 6.0 the archive lists the next release only on 8 April 2026 (WordPress.org Releases). Three days between the newest and the oldest branch is a long time in this situation, because the first release publicly documents which kinds of flaws were closed. How quickly a published flaw turns into attacks is covered in the article on the WordPress patch window.
The third: the effort for the team keeps growing, and with it the pressure to move the line again. Branch 4.7 was released on 6 December 2016 and has received 37 point releases since, six of them in 2026 alone (WordPress.org Releases). At the end of August 2026 the security team also reported a substantial increase in incoming security reports over the past year, much of it because AI models make code analysis easier; as part of a tighter release process, it is now scheduling upcoming security releases in advance (WordPress Security Team). Each of those dates means one release per affected branch, currently up to 25 at once.
Courtesy is not a commitment
The second bottleneck: PHP underneath the old branch
An older WordPress branch does not just pin down its own code, it also determines which PHP versions can run underneath. The core team's handbook keeps a compatibility table for this. For WordPress 4.7 it ends at PHP 7.1 (Make WordPress Core), and PHP 7.1 has received no security updates since 1 December 2019 (The PHP Group). A shop on 4.7.37 therefore has a freshly patched WordPress core on a runtime that has not been maintained for almost seven years.
| WordPress branch | Highest compatible PHP version (Make WordPress Core) | Security support for that PHP version (The PHP Group) |
|---|---|---|
| 6.9 to 7.1 | PHP 8.5 | until 31 December 2029 |
| 6.7 and 6.8 | PHP 8.4 | until 31 December 2028 |
| 6.4 to 6.6 | PHP 8.3 | until 31 December 2027 |
| 6.1 to 6.3 | PHP 8.2 | until 31 December 2026 |
| 5.9 and 6.0 | PHP 8.1 | ended on 31 December 2025 |
| 4.7 to 5.8 | PHP 7.1 to 8.0 | ended, most recently on 26 November 2023 (PHP 8.0) |
The table shows a limit that appears in no release post. Every branch up to and including 6.0 can only run on PHP versions that no longer receive security updates. After 31 December 2026, 6.1 to 6.3 join them, because security support for PHP 8.2 ends then (The PHP Group). The WordPress core on these branches is patched, the layer underneath is not. How a PHP change is planned and tested is covered in the article on PHP end-of-life management; the deadlines that come on top for operating system and database are listed in the overview of operating system and database end of life.
Plugins and themes go their own way
Automatic updates: the route by which backports arrive
Backports are designed to arrive without any action. Automatic background updates have existed since WordPress 3.7 (WordPress Developer Resources). Existing installations receive minor updates by default, meaning maintenance and security releases within their own branch. New installations from WordPress 5.6 onwards additionally receive major versions automatically, unless WordPress detects a version control checkout (WordPress Developer Resources). A site that was set up before WordPress 5.6 and not reconfigured since therefore stays on its branch and receives the point releases there.
The default can be overridden, for example by hosting providers, agencies or deployment pipelines that want to apply updates in a controlled way. That is an understandable reason, but it creates an obligation: whoever switches the automation off has to apply every security release themselves. Who updates which layer in day-to-day operations is covered in the article on responsibilities between hosting provider and maintenance. The behaviour of the core is controlled in wp-config.php through the constant WP_AUTO_UPDATE_CORE. With the value minor, minor updates stay on and major versions stay off (WordPress Developer Resources).
// Minor updates (maintenance and security) automatic, major versions not
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// Only set with your own routine for security releases: switches off
// every automatic update, including the backports to your branch
// define( 'AUTOMATIC_UPDATER_DISABLED', true );The documentation explicitly discourages switching minor updates off (WordPress Developer Resources). Anyone who does so anyway, for instance because changes are only ever rolled out from a repository, needs another route that verifiably achieves the same after every security release. Conversely, even with the automation switched on, it remains open whether it actually ran. Missing write permissions on the file system or a filter in a plugin can prevent a background update without anything showing on the front end. A short check after every security release is therefore part of the routine.
- After every security release, query the installed version, for instance with WP-CLI using wp core version, and compare it with the patched version of your branch from the release post or advisory.
- Check whether WP_AUTO_UPDATE_CORE or AUTOMATIC_UPDATER_DISABLED are set and whether a plugin changes the filters for core updates.
- Leave file permissions so that WordPress can update the core, or deliberately run a deployment route that rolls out point releases promptly.
- Where backports arrive in stages, repeat the check for older branches a few days later.
- Record the result: date, branch, old and new version. In a security incident this is the evidence that the flaw had been closed.
When the move to 7.x is due
A point update on the old branch is enough for the current flaw. Other criteria help with the question of how long a branch remains viable. A fixed end date from the WordPress project is not one of them, because none is published for branches below the most recent version. The decision therefore lies with the operator, and it can be tied to six triggers.
PHP deadline of the branch
Once the highest compatible PHP version leaves security support, the branch can no longer run on maintained PHP. For 6.1 to 6.3 this is the case after 31 December 2026.
Plugin requirements
If a business-critical plugin requires a newer core in its next version, the site is stuck on the old plugin version, including its future flaws.
Distance to the current branch
The more major versions lie between the site and the current state, the bigger the jump. Across more than two major versions, the documentation advises considering an incremental approach.
Next shift of the line
So far, every restriction of backporting hit the oldest branches first. Anyone on 4.7 to 4.9 has the smallest cushion.
No entitlement to the fix
Backports are made as a courtesy and only where the security team considers them necessary. Older branches have no reliable commitment for the next flaw.
Work that is planned anyway
If a server move, a PHP change or a theme refresh is coming up, the branch change can go into the same maintenance window and be signed off with the same tests.
The advice on an incremental approach is in the upgrade guide: anyone upgrading across more than two major releases should consider upgrading incrementally to avoid potential conflicts and minimise the risk of database damage (WordPress Developer Resources). A workable rule of thumb: at the latest when the branch can only run on a PHP version without security support, the move belongs in the next maintenance plan. Sites on 6.1 to 6.3 have until the end of the year; sites on 6.0 or older have already crossed that line. Every intermediate step is rehearsed in a staging environment before it goes live.
A maintenance plan for older branches
The sections above add up to a five-step routine. It does not require a site to move to 7.x immediately. It ensures that the site is verifiably patched on its branch for as long as backports keep coming, and that the change happens in good time before the next hard limit.
Version inventory
Record for every site: branch and exact version, PHP version, database version and the automatic update setting. Without this list there is no way to tell after a security release which sites are affected.
Determine the target version per branch
After every security release, read the patched version of your branch from the release post or advisory. On 22 September 2026 this was version 6.8.10 for branch 6.8 (Advisory GHSA-7hp8-65ch-5whp).
Verify arrival
Within a defined time window, check whether every site has reached the target version and apply deviations by hand. If backports arrive in stages, the check is repeated for older branches.
Record the PHP deadline
For every site, note in the maintenance calendar the end of security support for the PHP version in use and for the highest PHP version the branch supports.
Set the date for the move
Set a date for the branch change that lies before this PHP deadline, with an inventory of plugins, a staging test, a current backup and a prepared way back.
Record for every site: branch and exact version, PHP version, database version and the automatic update setting. Without this list there is no way to tell after a security release which sites are affected.
After every security release, read the patched version of your branch from the release post or advisory. On 22 September 2026 this was version 6.8.10 for branch 6.8 (Advisory GHSA-7hp8-65ch-5whp).
Within a defined time window, check whether every site has reached the target version and apply deviations by hand. If backports arrive in stages, the check is repeated for older branches.
For every site, note in the maintenance calendar the end of security support for the PHP version in use and for the highest PHP version the branch supports.
Set a date for the branch change that lies before this PHP deadline, with an inventory of plugins, a staging test, a current backup and a prepared way back.
The plan sounds like administration, but in an emergency it saves the decisive hours. Without an inventory, the response to a security release starts with the question of which sites are affected at all. With an inventory, it starts with checking whether the fix has arrived. For the backup before the branch change, the same applies as for any larger intervention: it has to be restorable, not merely present, which a backup service with tested restores covers. How to place the change itself in low-revenue periods is described in the article on maintenance windows without revenue loss.
Branch policy as part of WordPress maintenance
WordPress branch policy shifts two tasks onto operators that many are not aware of: proving that a fix has arrived, and deciding when to leave a branch. In our WordPress maintenance both are part of the fixed routine. We distinguish between security-related minor updates and major versions, keep track of branch, PHP version and update setting for every site, and after every security release compare the version actually installed with the target version. We apply missing updates, first on staging, then live. As a rule, we replace automatic minor updates with controlled, tested updates; that is exactly why the check after every security release is not an extra but a requirement.
For sites on older branches we plan the move as a project of its own: an inventory of plugins and their minimum requirements, the PHP change, a step-by-step update through intermediate versions, testing of the core functions and a prepared way back. Security-relevant updates run through our security updates service with a check against the components in use, and monitoring watches availability after every intervention. The response times that apply are set out in the SLA maintenance contract.
Related Articles
Moving Shop Servers Without Losing Orders: A Runbook
Resolvers may keep serving stale DNS answers for 1 to 3 days. How a shop moves servers without losing orders, cron jobs or payment notifications.
Hosting provider or maintenance: who patches what
Where the hosting provider’s responsibility ends and maintenance begins: a matrix across every layer of the shop, questions to ask and clear handover points.
End of support under the shop: OS and database
Debian 11, MariaDB 10.6 and MySQL 8.0 dropped out of maintenance in 2026. How to inventory distribution, database and PHP and plan the upgrades with lead time.