WordPress released a security update on 28 October 2026 that included a fix for a flaw in its own upgrade process. The flaw can lead to remote code execution, which means someone running their own code on your server, during the upgrade window. On 3 November the US cyber security agency CISA added it to its list of vulnerabilities known to be exploited.
If your site runs WordPress, there's one number worth knowing today and one person worth being able to name.
First, does this apply to you?
This is a flaw in WordPress itself, the core software, not in a plugin or a theme. If your site isn't built on WordPress, this one isn't yours. That covers Wix, Squarespace and Shopify, and sites built in code without WordPress.
If you're not sure what your site runs on, the people who built it will know in a sentence. The question is whether it's WordPress, and if it is, which version.
What the flaw lets someone do
The CVE record, written by the security firm Wordfence, says the cause is predictable, web-accessible staging paths used during full-package core upgrades. In plain terms, while a full WordPress update runs, it uses places on the server whose addresses can be guessed and reached from the web. The record says that makes it possible for someone with no account on the site to run code on the server during that window.
WordPress's own announcement describes it as a weakness in the upgrade process that can lead to remote code execution during the upgrade window, and credits a researcher, Umut Bayram, with reporting it. WordPress recommended updating immediately.
The record scores it 8.1 out of 10, which is high, and marks the difficulty of the attack as high. My reading is that the difficulty is the timing, because the attack has to land inside that window. The record doesn't say so in those words.
What happened, and when
WordPress released 7.1.4, a security release covering several issues, on 28 October. The CVE record gives the same day as its disclosure date and was published on 31 October. On 3 November CISA added the flaw to its Known Exploited Vulnerabilities catalogue with a due date of 6 November. CISA's own assessment in the CVE record lists exploitation as active.
The listing tells us that somebody is exploiting it. It doesn't tell us when that started, which could have been before the fix existed or after, and neither source says. It doesn't say how widely, or against which sites either.
The catalogue entry also carries a marker called forensic triage, set to yes, and its required action points to CISA's forensic triage requirements. I haven't read those requirements, so I won't describe them. My reading is that CISA wants agencies to look for signs that something already happened, not only to patch. The Wordfence advisory the entry links to sits behind a bot check, so I haven't read that either.
How to check
The version is shown inside the WordPress admin area, so whoever has a login can read it in seconds. If that isn't you, the question for whoever looks after the site is which WordPress version it's on and when it last updated.
The CVE and NVD records list affected releases from 4.7 through 7.1.3, and a first fixed release for every line, including 7.1.4, 7.0.8, 6.9.11 and 6.8.12. WordPress says it backported the fixes to every branch that still gets security fixes. When I checked the WordPress.org update service on 5 November, it was offering automatic updates for every line down to 4.7.39.
Then sort yourself into one of these, because what happens next is different for each.
The fixed release for your line, or a later one.
The fix is on. That isn't the same as knowing nothing happened beforehand, which is the next section.
An earlier number on your line.
The fix isn't on. Raise it today with whoever maintains the site.
You can't read the version, or you don't know who can.
That's a bigger finding than this flaw.
A host or an agency looks after updates.
Forward them this and ask which version the site is on and the date it went on.
Being on a fixed version doesn't tell you what happened before
Installing the fix closes the flaw from that point on. It doesn't undo anything that happened earlier, and it doesn't tell you whether anything did. The record doesn't say when exploitation began, so the period worth asking about is the whole time the site ran an affected version, not just the days since CISA's listing.
Working out whether something happened isn't a do-it-yourself job. It needs someone with access to the server, which means your host, your developer or a security professional. The things worth asking for are the server and access logs for that whole period, as far back as retention allows, a check for administrator accounts nobody recognises, and a look for files that changed when nobody was working on the site. Ask sooner rather than later, because logs get discarded after a set period.
If anything does turn up, don't tidy it away before someone has looked. Clearing it up first is the fastest way to lose any chance of understanding what happened.
Who confirmed the update went on?
WordPress says that sites which support automatic background updates will begin updating on their own. That's the vendor's statement about the software. Whether yours is set up that way depends on the host and on how the site was configured, so it's a question for them and not something to assume.
The gap is often not the software. It's that everyone assumed someone else had it. The someone can be you with a reminder in your calendar, your host if their plan covers core updates and you've confirmed that it does, an agency you already work with, or a care plan like the one I run. Disclosure, since I've just named my own: that last one is a service I sell. What matters isn't which. It's that somebody could tell you today which version your site is on and when it last changed.
Pages worth acting on
Related page
Website care and growth plans
Updates, security checks and routine monitoring after a site is live, so a security release going on is somebody's job rather than nobody's.
View pageRelated page
WordPress performance optimisation
Behind-the-scenes work on complex WordPress and page-builder sites, for owners and for the agencies who hold them.
View pageWhat to read next
Is your WordPress site patched against CVE-2026-87902?
WordPress patched a critical flaw on 22 September and CISA added it to the actively exploited list three days later. Many sites installed the fix on their own. Here's how to confirm yours did.
Read articleIs your All-in-One WP Migration plugin patched against CVE-2026-19949?
A migration plugin gets used once and then sits there for years. This one has a serious flaw fixed in August, it's on over five million sites, and nothing about your day tells you it's installed.
Read articleAre your iPhone, iPad and Mac covered by the fix for CVE-2024-27834?
Apple released the fix in May 2024, and CISA listed the flaw as exploited on 4 November 2026. The question worth asking is what software your business's Apple devices are running, and who knows.
Read articleAbout this notice
Published 2026-11-05 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
Could you say which WordPress version your site is on right now?
If nobody can answer that within a day, that's the thing worth fixing before the next one lands. Send me the address and I'll tell you what I can see from the outside.