On 22 September 2026 WordPress issued an emergency release to close a flaw rated critical. Within hours, automated attempts to exploit it were being recorded in the wild. If you run a WordPress site, this is one to act on rather than file away, and the reasons it turned dangerous so quickly are worth understanding whatever platform you use.
Almost every website application is built from many small files that get loaded as they are needed. A page request comes in, the application works out which file answers it, and loads that file. That decision is usually made partly from the web address the visitor typed, because that is the whole point of a web address – it tells the site what you want.
The danger is in the join between those two things. If any part of the visitor’s request is allowed to influence which file gets loaded, and the application does not rigorously check the result before loading it, a visitor can ask for a file that was never meant to be reachable. The usual trick is to include ../ sequences in the request, each one meaning “go up a directory”, until the path escapes the folder the application intended and lands somewhere else on the server.
That is a path traversal. On its own it is a serious information leak. It becomes far worse in a language like PHP, because loading a file there does not mean displaying it – it means running it. So if an attacker can steer that load at any file on the server that contains code they control, or that can be made to do something useful, the flaw stops being about reading files and becomes about executing commands. That is remote code execution, and it is the point at which a website stops being yours.
Two further details decide how bad any given instance is. The first is whether the attacker needs to log in. A flaw that requires an administrator account is a problem; one that needs no account at all can be attacked by anything that can reach your site, which in practice means every automated scanner on the internet. The second is how many sites are affected. A flaw in one obscure plugin is a bad day for its users. A flaw in the core of the software running a large share of the web is a bad week for everybody.
The September flaw, catalogued as CVE-2026-87902, sits in the part of WordPress that decides which theme template should render a page. A crafted request could make that decision resolve to a readable PHP file outside the theme directories entirely. No login was required. WordPress rates it critical, with a CVSS score of 9.2.
The fix shipped on 22 September as WordPress 7.1.2, and – this is the part worth noticing – was backported to every branch still eligible for security fixes, all the way down to 4.7.37. Releases were issued for more than twenty separate branches on the same day. That tells you how seriously it was taken, and it also means that whichever version of WordPress you are on, there is almost certainly a patched release of your branch waiting for you. If you are on 7.1.x you want 7.1.2. On 7.0.x, 7.0.6. On 6.9.x, 6.9.9. On 6.8.x, 6.8.10. Older branches each have their own.
Turning this from file disclosure into code execution needed two additional conditions to be true. The theme in use had to contain a top-level folder whose name began with page-, which is a perfectly ordinary way to organise page templates and is present in a number of widely used themes, including some that shipped with WordPress itself. And the server had to have a suitable PHP file lying around that could be pushed into doing something useful – a well-known technique that works against a great many standard server configurations.
It is tempting to read “conditional” as “probably not me”. We would not recommend it. Neither condition is exotic, neither is something a site owner would normally know the state of, and finding out for certain takes longer than updating does.
The security firm Patchstack reported seeing the first probes against its customers’ sites at 11:49 UTC on 22 September – the same day the fix was published – and attempts to write files to the server by mid-afternoon. By the following day it was describing off-the-shelf scanning tools built for this specific flaw.
That timeline is becoming normal, and the reason is straightforward. Every security release is accompanied by a public record of exactly what changed. Reading that record backwards to work out what the flaw was is a skill that used to take a specialist days, and now increasingly does not. The patch is the starting gun, and the gap between a fix being published and being attacked has been shrinking for years.
The practical consequence is uncomfortable: a maintenance policy built around updating at a convenient moment is no longer a maintenance policy. If your site is patched a week after a fix ships, you were exposed for a week, and in that week the exploit went from private to packaged.
Nothing about the underlying mistake is specific to WordPress – it is one of the oldest classes of web vulnerability there is, and every platform has had its turn. What differs is the response. Some projects ship a fix for one supported branch and leave everyone else to upgrade. WordPress patching twenty-five branches in a day is unusually good behaviour, and if you run something else, it is worth knowing today rather than in an emergency how far back your platform’s security support actually reaches, and whether the version you are on is still inside it.
The same thinking applies to the layers underneath. An out-of-date PHP version, an unpatched server, an abandoned plugin nobody has looked at since it was installed – each one is a place where the next flaw of this kind will land, and none of them announce themselves.
Keeping a site current is not difficult work, but it is relentless, and it only counts if it happens promptly. That is the awkward combination: low skill, high frequency, and a real penalty for being a few days late.
If you would rather not be the person tracking this, we offer a Custom Yearly Upgrade Service at £100 per year. We keep WordPress core, every plugin and every theme up to date on your site, with a database backup taken before each run and an automatic rollback if an update breaks anything. A flaw like this one is patched on your site as a matter of routine rather than as a matter of you noticing. It can be added to any hosting account with us.
If you are unsure whether your site is affected or you would like us to look at it, open a ticket from your client area and we will check it for you.