What we know about CVE-2026-119977, who is affected, and why nobody can yet say how many sites were hit.
- Why the update that protects a WordPress site is also the moment it can be attacked.
- Why WordPress rates this flaw Low while CISA lists it as actively exploited.
- Who is really exposed, and why nobody can yet say how many sites were hit.
What happened
On November 3, 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) added a WordPress core flaw to its Known Exploited Vulnerabilities catalog. US federal civilian agencies have until Friday, November 6, to deal with it.
The flaw is CVE-2026-119977. It lets an attacker with no account run code on a server, but only for the few seconds while WordPress is updating itself.
The short answer on who was affected: every WordPress branch from 4.7 through 7.1 had the flaw until it was patched, but no victim has been named and no one has published a count of compromised sites. The attack numbers in circulation are blocked attempts. This post sticks to what is known as of November 5.
What is CVE-2026-119977?
It is a race condition in WordPress core, not in a plugin or theme.
During a core update that uses the complete package, WordPress unpacks the new files into a temporary folder inside wp-content/upgrade. Before the fix, that folder had a predictable location and could be reached from the web. An attacker who reaches the temporary files before the update finishes and cleans up can run code on the server.
Three things have to line up:
- A core update using the complete package has to be running. Plugin and theme updates do not trigger it.
- The upgrade folder has to be reachable over the web, with PHP running there.
- The attacker has to hit the window. In lab tests the folder existed for only seconds, according to an analysis of Wordfence's findings.
The fix makes the folder name unpredictable. Patchstack traces the risky code back to WordPress 2.8.
Timeline
The patch and the first probing arrived on the same day. Click a bar to jump to a stage.
- Stage 1 · The fixOct 28 – Oct 29
WordPress patches every supported branch at once.
WordPress ships 7.1.4
The security release fixes 22 vulnerabilities across 17 advisories. The upgrade flaw is credited to researcher Umut Bayram of Picus Security.
Fixes reach every branch WordPress still patches, down to 4.7.39. Sites with automatic background updates start updating on their own.
WordPress rates it Low
WordPress publishes its advisory for the flaw and rates the severity Low. No CVE number is attached to it yet.
- Stage 2 · ProbingOct 28 – Nov 2
Attackers start looking for the temporary files within hours.
First hit nine minutes after the firewall rule
Wordfence deploys a firewall rule for paying customers about three hours after the release. It reportedly sees the first matching request nine minutes later. Free users get the rule on November 27.
18,500+ requests in 21 hours
Wordfence reports more than 18,500 requests aimed at the temporary installer paths in the first 21 hours after disclosure.
A honeypot catches attempts
Previdian's honeypot records three exploitation attempts from a UK address.
The CVE is published
Wordfence, as the issuing authority, publishes CVE-2026-119977 with a CVSS score of 8.1 (High).
- Stage 3 · ExploitedNov 3 – Nov 6
CISA confirms attacks in the wild and sets a deadline.
CISA lists it as exploited
CISA adds the flaw to its Known Exploited Vulnerabilities catalog. It gives no details about the attacks and lists ransomware use as "Unknown".
12,632 attacks blocked in a day
Wordfence reports 12,632 attacks blocked in the previous 24 hours. Code claiming to exploit the flaw starts showing up on public exploit sites. We have not verified it.
Federal deadline
US federal civilian agencies must have dealt with the flaw by this date.
Who is affected?
The honest answer has three layers, and they get smaller as you go.
- Sites with the flawed code
WordPress runs 39.5% of all websites, according to W3Techs. Any install from 4.7 through 7.1.3 that has not moved to its branch's fixed release has the flaw. That is not the same as being exposed, and no public figure says how many sites are still unpatched.
- Sites that are really exposed
These need the flawed code, a reachable upgrade folder and a complete-package core update in progress. The sites easiest to miss are forgotten ones: old staging copies, campaign microsites and installs nobody has logged in to for a year.
- Sites that were actually hit
Nobody knows yet. Wordfence's counts are attempts its firewall stopped. As of November 5, we found no named victim, no named attacker and no confirmed compromise tied to this flaw.
Hosting matters too. IONOS says customers on its managed WordPress hosting with automatic updates need to do nothing, while anyone running their own install must update. Pantheon says it has deployed platform-wide protections and still tells customers to update.
No confirmed victims is not proof that nothing happened. The temporary folder is removed when an update completes, so a successful attack may leave little trace in that location. CISA's catalog entry also carries a forensic triage flag and points agencies to its forensics requirements, in addition to patching.
The federal deadline binds only federal civilian agencies, though CISA urges everyone else to prioritize the fix as well.
Low or High? Why the ratings disagree
This flaw has very different ratings, and each answers a different question.
- WordPressLow
Its advisory describes a race an attacker must win against the update itself.
- Wordfence (CVE issuer)8.1 High
Attack complexity is high, but no login and no user action are needed, and a won race means code execution.
- PatchstackHard to use
Dave Jong wrote that the team “would not call it practical to exploit”.
- CISAExploited
Its listing answers a different question: is anyone trying this in the real world? Yes.
The attack pattern shows why a short window may not protect anyone. Wordfence's data, as analyzed by others, shows its two largest sources spent about 14.5 hours repeatedly polling small groups of sites. That is consistent with an attacker waiting for a target to start updating. And on an unpatched site, the window reopens with every update of this kind, including unattended ones.
WordPress teams have had little time to rest. 7.1.4 is the seventh core security release since July. After July's wp2shell patches, public exploits appeared within a day.
What to do now
- 1. List every WordPress install you run.
Include staging sites and old microsites. Check each version against the fixed list below.
- 2. Block web access to wp-content/upgrade first, then update.
The risk appears while an update runs, so close the folder before you start. Do it at the web server or CDN, confirm it returns a 403 and that the folder cannot be listed, and test on a non-production site first. Patchstack warns that a normal PHP-level firewall will not stop these requests.
- 3. Update to the fixed release for your branch.
Then confirm it applied. The latest release is 7.1.4.
- 4. Move anything on 4.6 or older.
Those versions get no fix. WordPress's security backports stop at 4.7, and that floor should not be read as "older versions are safe".
- 5. Check your logs from October 28 onward.
Look for PHP requests under
wp-content/upgradeand repeated polling from a single source, especially around the time each site updated. Logs age out, so save them now. If the logs for an update window are gone, record that as a gap rather than assuming all is well. - 6. Look for changes you cannot explain.
New administrator accounts, unknown plugins, PHP files in
uploads, a modifiedwp-config.phpor.htaccess, failed core checksums, and web server processes starting shells. If something turns up, isolate the site, preserve evidence, rebuild from a known-good copy and rotate credentials.
Fixed versions by branch
7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34, 4.7.39.
WordPress only actively supports the latest release, so a backport keeps an older branch patched for this issue but does not bring it up to date.
CVE-2026-119977: FAQ
What is CVE-2026-119977?
A race condition in WordPress core. While a core update using the complete package is running, the new files sit for a few seconds in a temporary folder that, before the fix, had a predictable, web-reachable location. An attacker with no account who reaches them in time can run code on the server. It is fixed in WordPress 7.1.4 and backported to every branch down to 4.7.39.
Which WordPress versions are affected?
WordPress 4.7 through 7.1.3, on any branch that has not moved to its fixed release. Versions 4.6 and older get no fix at all and need to move to a supported release.
Has anyone been hacked through this flaw?
CISA says the flaw is being exploited, but as of November 5 no victim has been named and no compromise tied to it has been confirmed. The published numbers are blocked attempts. A successful attack may leave little trace, so a lack of reports is not proof that nobody was hit.
Is my site vulnerable if it has automatic updates on?
It should receive the fix on its own, but check the version. Automatic core updates can be turned off, and sites managed through Composer or a deployment pipeline follow their own schedule.
Do plugin or theme updates trigger the flaw?
No. Reports describe it as limited to complete-package core updates.
Should I delay updating to avoid the window?
No. Staying unpatched keeps the flaw in place for every future update, and leaves the site open to the other 21 vulnerabilities fixed in 7.1.4. Block the folder, then update.
Read next on the Cloudaware blog
Sources
- WordPress – WordPress 7.1.4 release (October 28)
- WordPress – Advisory GHSA-4w3m-c66w-69mg (October 29)
- CISA – Known Exploited Vulnerabilities catalog: CVE-2026-119977 (November 3)
- NVD – CVE-2026-119977
- Patchstack – WordPress 7.1.4 Security Release
- The Hacker News – CISA Confirms Hackers Exploiting WordPress Core Flaw During Software Upgrades
- BleepingComputer – CISA flags WordPress RCE flaw as actively exploited in attacks
- Qualys – CISA Warns of WordPress Vulnerability Exploited in the Wild
- Threat Defence – Hunting the 7.1.4 Upgrade RCE
- DEV Community – The WordPress Core RCE That Only Exists During an Update
- IONOS – WordPress 7.1.4 security update
- Pantheon – WordPress 7.1.4 release note
- W3Techs – Usage statistics of WordPress
Facts as of November 5, 2026. Attack counts are vendor telemetry of blocked attempts, not confirmed compromises.