WordPress released a security update on 22 September 2026 and told site owners to install it immediately. Three days later, on 25 September, the US cyber security agency added the flaw behind it to their list of vulnerabilities known to be under active attack.
That sounds alarming, and the calm version's more useful. WordPress installs security updates on its own on a normally configured site, so yours may already have taken this one. The job this week's to confirm that rather than assume it, and it takes about a minute.
First, does this apply to you?
This is a flaw in WordPress itself, not in a plugin or a theme.
If your site was built on Wix, Squarespace, Shopify, or as a custom-coded site, this one isn't yours and you can stop reading here. If you're not sure what your site runs, the quickest tell is how you log in to edit it. A web address ending in /wp-admin means WordPress.
What the flaw lets someone do
When someone visits your site, WordPress builds the page by loading a series of PHP files. Those are instructions that run on the server before anything reaches the visitor's browser.
This flaw let someone point that loading process at a PHP file it was never meant to load, without logging in as anyone. No password, no stolen account, nothing for you to click. And because those files run rather than simply being displayed, loading the wrong one is the problem in itself, not a step towards it.
On some server setups it could be pushed further and used to run commands the attacker chose. That's the point at which a site can be made to do the things people worry about, like sending spam, redirecting visitors, or collecting what people type into forms. Those are examples of what becomes possible once someone can run commands, not things anyone's reported happening to a particular site.
It doesn't affect every site equally, and the conditions are narrower than the headlines suggest. Robert Ressl, the researcher who found and reported it, lists five separate things that have to line up before the file loading works at all, and a further set of server conditions before it can reach running commands. That's a reason to check where you stand, not a reason to panic.
Why this one got attention
Two things lifted it above the ordinary run of security updates.
The first's timing. WordPress published the fix on 22 September. Patchstack, a WordPress security firm, blocked an attempt to exploit it at 11:49 UTC the same day, and reported an attempt to write a file to a server less than four hours later.
The second's the escalation. On 25 September the US Cybersecurity and Infrastructure Security Agency added it to their Known Exploited Vulnerabilities catalogue as CVE-2026-87902. Entries reach that list on evidence of active exploitation rather than on prediction. The entry sets a remediation date of 28 September for US federal civilian agencies, and CISA "encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities".
That directive binds US Federal Civilian Executive Branch agencies. It doesn't directly bind an Australian business, and it's quoted here as a read on how seriously the people with the best telemetry are treating it.
On severity scores, there's no single agreed number and it matters less than it looks. WordPress called it "a critical severity security vulnerability" in its own release. Two different scoring systems have landed on two different figures, which is what happens when a flaw's serious but conditional. The fix is the same either way.
Your site may have already taken the fix
This gets left out of the coverage and it's the most useful thing to know.
WordPress applies minor and security releases automatically by default. A security release like this one is exactly what that system exists to deliver, so on a normally configured site the update may well have installed itself.
But default behaviour isn't evidence that it happened here, and that distinction's the whole reason to look. Automatic updating can be switched off in the site's settings, disabled by a plugin or by a developer's code, blocked when a site's files are managed by a deployment system rather than edited directly, or prevented by file permissions on the server. None of them are unusual on a site several people have worked on over several years, and none of them announce themselves. Which is why the practical first check is the version number, not a judgement about how the site is run.
How to check
Log in and go to Dashboard, then Updates. The screen tells you which version of WordPress you're running.
WordPress fixed this across every affected line from 4.7 onward, so there's a patched release for your line. The current ones are 7.1.2, 7.0.6, 6.9.9 and 6.8.10, and the oldest is 4.7.37.
One thing that's easy to get backwards: a higher number isn't automatically a safer one. 7.0.0 is a bigger number than 6.9.9 and it's still vulnerable. What matters is your patch level within your own version line. If you're on the 7.0 line you need 7.0.6 or later on that line, and if you're on an older line than the four above, WordPress publishes the full list of releases so you can find yours.
What you do with that answer isn't a job for this article. Applying a core update is a change to a live site, and whether it's routine or risky depends on the theme, the page builder and the plugins sitting on top of it. That's a judgement for whoever maintains the site.
So the useful thing you can do today is find the version number and put it in front of that person, with one question: are we on the patched release for our line, and if not, when are we going on it?
Compare what it's offering against what you're on. If only the last of the three numbers changes, so 6.8.9 becoming 6.8.10, that's the security update and it's the routine one. If either of the first two numbers moves, say 6.8 to 6.9 or 6 to 7, that's a bigger release that can affect your theme, your page builder and your plugins. That one is worth handing to your host or whoever maintains the site rather than clicking yourself, and there's no harm in leaving it for a day while you ask.
Then sort yourself into one of these, because what happens next is different for each.
Your version's at or past the patch level for your line.
You're patched. That isn't the same as knowing nothing happened earlier, which is the next section.
There's an update waiting.
Tell whoever maintains the site today rather than leaving it for the next scheduled round.
You can't log in, or you don't know who does.
That's the finding, and it's a bigger one than this flaw. Somebody needs to hold those keys and know when they last used them.
Someone else maintains the site.
Forward them this and ask when the core was last updated, and when it's going on if it hasn't.
Core updates and plugin updates are two different jobs
If you build your own pages in Elementor, Divi, or another page builder, this is the distinction that matters most, and it's the one that catches people out.
Your Updates screen lists plugins and themes, and below them WordPress itself. Working through the plugin list, which is the routine most people have, doesn't install a WordPress core update. This flaw was in WordPress core. A site could've been completely current on every plugin and still running the vulnerable core version.
The core update sits at the top of that screen, above the plugin list. That's the one that mattered here.
Updating closes the door. It doesn't tell you who came through first.
Installing the fix stops the flaw being used from that point on. It doesn't undo anything that happened before, and it doesn't tell you whether anything did. A site was potentially exposed from at least 22 September, when the first attempts were observed, until the moment its own patch went on. That could be hours or days depending on the site.
Working out whether something happened isn't a do-it-yourself job, and anyone who tells you they can answer it from looking at your website's address is guessing. It needs someone with access to the server, which means your host or a security professional.
What you can reasonably do is ask, and ask precisely. If your site was running an affected version at any point after 22 September, ask your host to preserve and review the server logs from that date, or further back if they still hold them, and to look for PHP files created or changed since then and for administrator accounts nobody recognises. Ask sooner rather than later, because logs get discarded after a set period, and once they're gone the question's much harder to answer.
Two things worth knowing before you start. Plenty of hosting plans exclude this kind of investigation, and if yours does, it's a job for a security professional rather than something to push. And if anything does turn up, resist the urge to tidy it away first, because deleting the evidence is the fastest way to lose any chance of understanding what happened.
Who's actually responsible for the updates?
I work on WordPress sites most weeks, mostly speed and performance rescues, so this isn't a pitch to go and use something else.
The honest point is smaller and more practical. A week like this one turns the update routine into a security control rather than housekeeping, and a control only works if it's somebody's job. On a lot of the sites I'm called into, it's nobody's - not because anyone decided that, but because it was never assigned.
Disclosure before I name the options: one of them is a service I sell. That someone can be you with a recurring reminder, your hosting company if their plan covers core updates and you've checked that it does, an agency you already work with, or a care plan like the one I run. What matters isn't which. It's that you can name them, and that they'd know when your core was last updated without having to go and look.
The routine worth keeping
This particular flaw will be replaced by another one. What's worth keeping from the week is the routine: which version you're on, and who checks it. Those two questions outlast every CVE.
Pages worth acting on
Related page
Website care and growth plans
Ongoing maintenance, updates and monitoring, so core updates are somebody's job rather than nobody's.
View pageRelated page
WordPress performance optimisation
Behind-the-scenes speed work on complex WordPress and page-builder sites, for owners and for the agencies who hold them.
View pageWhat to read next
Custom-coded vs WordPress: a real-world speed comparison
The same local business, the same services, one website replaced by another, both measured with Google PageSpeed Insights on the same day. Not a laboratory test, but the closest the real world gets.
Read articleWebsite Redesign Central Coast: When Is It Time to Rebuild?
Most Central Coast business owners know their website isn't working well enough. The question is whether the answer is a quick improvement, a redesign, or a full rebuild. The difference matters a lot.
Read articleAbout this notice
Published 2026-09-26 and accurate to the sources linked above as at that date. Security situations move, so check the vendor's own advisory before you act on anything here.
This is general information about a published vulnerability. It's not advice about your site, which nobody can give without looking at it, and nothing here should be treated as a substitute for your own provider or a security professional.
Questions local business owners usually ask next
Not sure when your site last took a core update?
Send me the address and tell me who looks after it. I'll tell you straight what I can see from the outside and what only your host can answer.