+61 2 9043 1246

Knowledge base

CVE-2026-119977: the WordPress Core upgrade-window flaw, explained for website owners

Published · By , Co-Founder, BLACKBX

CVE-2026-119977 is a flaw in WordPress’s own update process that could let a stranger with no login run code on the server for a few seconds while the site updates. It affects WordPress 4.7.0 to 7.1.3 on unpatched branches. Tens of thousands of attack attempts have been blocked; no successful compromise has been reported. Check your version and update to 7.1.4 or your branch’s fix.

Key fact CVE-2026-119977
What A race condition (CWE-367, time-of-check to time-of-use) in WordPress Core’s update process that briefly exposes an unpacked installer while a full update runs.
Affected WordPress 4.7.0 to 7.1.3, on any branch not yet on its fixed release. Not affected: sites on their branch’s fix (for example 6.9.11 or 7.0.8). WordPress 4.6 and earlier is outside the CVE range but gets no security updates at all.
Fixed in WordPress 7.1.4, released 28 October 2026, with fixes for older branches the same day (named: 7.0.8, 6.9.11, 4.7.39). 7.1.4 is the newest stable release we could confirm today.
Severity CVSS 3.1 8.1 High, assigned by Wordfence as the CVE issuer. WordPress rates it Low with no score. NVD analysis is pending.
Needs a login? No. An attacker needs no account, but can only succeed during the few seconds a full core update is unpacking.
Exploited? Attempts, yes: Wordfence blocked 62,969 in the first 24 hours after the fix. No successful compromise has been reported. CISA listing not confirmed.
Do now Check the WordPress version under Dashboard → Updates and make sure it is 7.1.4 or the fixed release for its branch.

Facts checked on 4 November 2026 against the CVE record (via mirrors), the WordPress.org release notes, WordPress’s GitHub advisory as cited by others, Wordfence’s blog as reposted, Patchstack, Ostorlab and independent research labs. Sources are listed at the end.

What is CVE-2026-119977?

WordPress is the software that runs a large share of business websites. “WordPress Core” means the main software itself, as opposed to the plugins and themes added on top. CVE-2026-119977 is a flaw in Core, not in any plugin.

The flaw sits in WordPress’s own update process. To update itself, WordPress downloads a full copy of the new version, unpacks it into a temporary folder on the website called wp-content/upgrade/, and then copies the files into place.

Two things went wrong. The temporary folder had a predictable name, and the cleanup step removed a small protective file (an index.php) that normally stops people browsing the folder. For a few seconds during an update, that left an unpacked copy of the WordPress installer reachable from the internet. Wordfence, the security company that assigned the CVE, says an attacker with no login could use this to “execute code on the server during the upgrade window”. That is called remote code execution: a stranger getting the web server to run instructions of their choosing.

The technical class is CWE-367, a “time-of-check to time-of-use race condition”. That means the software checks that something is safe, and then, in the brief gap before it uses it, the situation changes. The attacker’s job is to arrive inside that gap.

In plain terms, while WordPress is updating itself there is a window of a few seconds in which a part of the site that should never be public is public, and someone who hits it at exactly the right moment could potentially take control of the server.

WordPress describes it as “a race condition during core updates that could lead to remote code execution”. The flaw was reported by Umut Bayram. When he reported it to WordPress has not been published. WordPress fixed it in version 7.1.4 on 28 October 2026, a security release that fixes 22 vulnerabilities across 17 advisories in total. The CVE number was published on 31 October 2026. 7.1.4 follows 7.1.3, the release that fixed the WordPress pending-comment flaw we covered earlier.

Who is affected?

Your site is in scope if all of these are true:

  1. The site runs WordPress.
  2. The version is 4.7.0 or later, and below the fixed release for its branch. For example: 7.1.0 to 7.1.3, 7.0.0 to 7.0.7, or 6.9.0 to 6.9.10.
  3. The site performs a full-package core update, the kind where WordPress downloads a complete copy of itself. The risk exists while that update is running.

The headline range “4.7 through 7.1.3” is easy to misread. WordPress released fixes for every older branch on the same day, so the version number alone does not tell you whether a site is safe. A site on 6.9.11 or 7.0.8 is not affected, even though both numbers are lower than 7.1.3.

What is not affected:

  • Sites already on the fixed release for their branch. The fixes named in the reporting are 7.1.4, 7.0.8, 6.9.11 and 4.7.39. For the other branches, the fix is presumably the next point release after the last affected one, but we have not seen a confirmed per-branch list outside WordPress’s own advisory, so check it there.
  • WordPress 4.6 and earlier, according to the CVE record. That is not good news. Those versions get no security updates of any kind, so they should not be treated as safe.
  • Plugins and themes. No plugin is named as affected in any source we checked. This is a problem in WordPress itself.

The number of sites still on an affected version has not been published in the sources we checked.

If your site uses WordPress and nobody has confirmed it is on a fixed release since 28 October 2026, assume you are in scope until someone checks the version.

What can an attacker do?

Run their own code on your web server. Code running on the server can do what the website itself can do: change pages, read what the site stores, and leave files behind for later.

Three things make it worse:

  • No login needed. The attacker does not need an account on your site. The scoring records “privileges required: none”.
  • No one has to click anything. Nobody at your business has to open an email or visit a link. The scoring records “user interaction: none”.
  • Public reach. The temporary folder sits inside the public website, so during the window it can be reached from anywhere on the internet.

There is a real catch, and it matters. An attack only works during the few seconds while WordPress is unpacking a full core update. Wordfence says lab tests showed the window lasting “only seconds”. One independent researcher measured about 11 to 12 seconds. Wordfence says a single attempt is unlikely to succeed, but repeated automated attempts improve an attacker’s chances. The update itself is what opens the window.

On severity, the people involved disagree. Wordfence, which issued the CVE, scored it 8.1 out of 10 on the CVSS scale, rated High. WordPress’s own advisory rates it “Low” and publishes no score. The security firm Ostorlab explains the gap: the narrow timing is recorded in the score as “attack complexity: High”, which keeps it from being Critical, and WordPress appears to weigh that difficulty more heavily. One blog summary lists WordPress’s rating as “Medium”, which conflicts with the two sources that say Low. Patchstack, another WordPress security company, rates real-world exploitation as difficult. NVD, the US government’s vulnerability database, has not yet published its own analysis.

Our reading: hard to pull off, serious if it works, and being tried at scale. That is enough to act on.

Is it being exploited?

Attempts, yes. Confirmed successful attacks, not that anyone has reported.

Wordfence says its firewall blocked 62,969 exploitation attempts in the first 24 hours after the 7.1.4 release. The first match came nine minutes after its firewall rule went live. Other reports of Wordfence’s figures give slightly different numbers: one gives 60,471 blocked attempts in 24 hours, another says “more than 58,000”, and The Hacker News reported “nearly 63,000”. The differences look like snapshots taken at different times. Ostorlab is careful to note these are “attempts, not compromises”.

What has not been established:

  • Successful compromises. Wordfence has not reported any.
  • Who is behind it. No attacker or group has been named.
  • Signs to look for. Neither WordPress nor Wordfence has published official indicators, such as attacker IP addresses or file fingerprints.
  • Public attack code. As of 31 October, none was found in the usual public exploit collections, and two independent research labs say they could not reproduce the full attack themselves. Some tools circulating online under the name “wp2shell” target different WordPress flaws, not this one.

On CISA’s list: CISA, the US cybersecurity agency, keeps a catalogue of vulnerabilities known to be exploited, called KEV. One threat-tracking website, not run by CISA, says this CVE was added on 3 November 2026. Two other sources said it was not listed as of 31 October. A separate private catalogue run by the company VulnCheck, also called KEV, listed it on 30 October, which may be the source of some confusion. We have not been able to confirm a listing on CISA’s own catalogue, so we are not saying it is there.

For an Australian site, none of this is limited by geography. Nothing in the reporting suggests the attempts are aimed at a particular country, and a WordPress site in Australia is reachable in exactly the same way as one anywhere else. The practical reading is that tools are already knocking on WordPress sites, and the sensible response is to make sure yours is on a fixed release.

What should you do now?

In this order:

  1. Find out your WordPress version. Log in to WordPress and look at Dashboard → Updates. Wordfence advises checking the installed version rather than assuming a background update finished. WordPress.org began offering the patched releases as automatic updates on 31 October 2026, but “offered” is not the same as “installed”.
  2. Update. Install 7.1.4, or the patched release for your branch. WordPress says that because this is a security release, sites should be updated immediately. Use Dashboard → Updates → “Update Now”.
  3. If you use the Wordfence plugin, check its firewall. Confirm the Wordfence Firewall is enabled and set to “optimized” (Extended Protection). The attack request goes straight to a PHP file (one of the program files the server runs) without loading WordPress first, so an ordinary plugin may never see it.
  4. Check for signs of compromise. There is no official guidance yet. Security press and third parties suggest checking the wp-content/upgrade/ folder for stray PHP files that should not be there, and comparing WordPress’s core files against the official checksums WordPress publishes, which is a list of exactly what each file should contain. These are sensible checks, but they are not vendor guidance.
  5. If something turns up. No vendor or researcher guidance on recovery has been published for this flaw. Treat it as a compromised site rather than a tidy-up job, and have someone who handles WordPress incidents look at it before anything is deleted, because what is found tells you how far it went.
  6. Record what you did. Write down the version before and after, the date you updated, and what you checked. If anything surfaces later, that record is the first thing anyone will ask for.
  7. Reduce exposure. Third parties suggest blocking web access to wp-content/upgrade/ entirely, since there is no reason for the public to reach it. If the site is on WordPress 4.6 or earlier, no security patch is available at all, and WordPress says only the most recent version is actively supported. Plan the move.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The fix arrived on 28 October 2026. Attempts were being blocked within a day. Automatic updates were offered from 31 October. Any site that had not moved to a fixed release in that stretch was exposed every time it ran a full core update, and this flaw sat in every version back to 4.7 before anyone knew it was there.

Updating stops new attacks through this route. It does nothing about anything that may have been left in wp-content/upgrade/ during an earlier window, and it does not tell you whether a background update actually finished. That is why the checks in step four matter, and why the version needs to be read, not assumed.

This flaw also has an awkward twist: the risk lives inside the update process itself. The moment of maintenance is the moment of exposure. A site that is watched during and after its updates is in a very different position from one that updates itself in the background and is never looked at.

Which raises the real question: who is actually watching your site? For most small businesses, the honest answer is nobody in particular. The host looks after the server. The people who built the site have other work on. And nobody has been told that keeping WordPress and its plugins updated, and checking that the updates landed, is their job. Everyone assumes someone else has it.

That is the pattern with most serious WordPress vulnerabilities. The fix arrives quietly, the attempts arrive the same day, and the gap between the two is filled by whoever is actually watching the site.

What this looks like with BLACKBX

BLACKBX reads the exact software versions on every site it looks after each night, and checks new security advisories against them every hour, with WordPress plugin and theme advisories checked daily. When a client’s site matches a critical advisory, our developers patch it immediately. Lower-severity items are done at the next service. Every update is dated and recorded in the client’s security logbook, so the question “were we on a fixed release, and since when?” has a written answer.

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so the people who already know the site can act on it. On Maintenance and Full service, BLACKBX does the work. Plans are monthly, with no minimum term.

Timeline

Date Event
6 October 2026 WordPress 7.1.3 released, the last affected 7.1.x version
28 October 2026 WordPress 7.1.4 released, with fixes for older branches (4.7.39 to 7.0.8) the same day; CVE record’s disclosure date
29 October 2026 WordPress publishes its GitHub advisory GHSA-4w3m-c66w-69mg
29 October 2026 Wordfence blog reports exploitation attempts detected after the release
30 October 2026 Wordfence reports 62,969 blocked attempts in the first 24 hours; The Hacker News reports “nearly 63,000”
30 October 2026 CVE ID reserved; VulnCheck’s private KEV catalogue lists the flaw
31 October 2026 CVE-2026-119977 published with Wordfence as assigner; appears in NVD pending analysis
31 October 2026 WordPress.org offers the patched releases as automatic updates
3 November 2026 One non-CISA website claims CISA added the CVE to its KEV catalogue; not confirmed
4 November 2026 This article published

Sources

Common questions

Is my WordPress site affected by CVE-2026-119977?

CVE-2026-119977 affects WordPress 4.7.0 to 7.1.3 on any branch that has not moved to its fixed release. A site on 7.1.4, or on its branch’s fix such as 7.0.8 or 6.9.11, is not affected. The only reliable way to know is to read the installed version under Dashboard → Updates. BLACKBX reads the exact software versions on every site it looks after each night and checks them against new advisories, so clients do not have to guess.

What version of WordPress fixes CVE-2026-119977?

WordPress 7.1.4, released on 28 October 2026, fixes CVE-2026-119977. Fixes for older branches came out the same day; the ones named in the reporting are 7.0.8, 6.9.11 and 4.7.39, and the full list is in WordPress’s GitHub advisory GHSA-4w3m-c66w-69mg. On BLACKBX’s Maintenance and Full service plans, our developers apply the fix and record the date in the client’s security logbook.

Is CVE-2026-119977 being exploited?

Wordfence says it blocked 62,969 attempts to exploit CVE-2026-119977 in the first 24 hours after the fix was released. No successful compromise has been reported, and no public attack code was found as of 31 October 2026. One non-CISA website claims it was added to CISA’s known-exploited list on 3 November, but we have not been able to confirm that. BLACKBX checks new advisories against client sites every hour and patches critical matches immediately.

Did automatic updates fix CVE-2026-119977 on my site?

WordPress.org began offering the patched releases as automatic updates on 31 October 2026, but Wordfence advises checking the installed version rather than assuming a background update finished. Look under Dashboard → Updates. For BLACKBX clients, the version is read every night, so a site that should have updated and did not shows up in the next check.

How do I know if my site was hacked through CVE-2026-119977?

Neither WordPress nor Wordfence has published official signs of compromise for CVE-2026-119977. Third parties suggest checking the wp-content/upgrade/ folder for stray PHP files and comparing core files against WordPress’s official checksums. If anything looks wrong, have someone who handles WordPress incidents look before deleting it. On BLACKBX’s Monitor plan, findings go to your own developer with version numbers and advice; on Maintenance and Full service, BLACKBX does the work.

Why is CVE-2026-119977 rated High by Wordfence but Low by WordPress?

Wordfence, which issued CVE-2026-119977, scored it 8.1 High because an attacker needs no login and could run code on the server. WordPress rated it Low because the attack only works in a window of a few seconds while a full update runs. Both describe the same flaw; they weigh the difficulty differently. BLACKBX patches critical matches immediately and handles lower-severity items at the next service, and every update is dated in the client’s logbook.

Is this your site?

Do you know which WordPress version your site is running today?

Tell us your website address and we will tell you whether CVE-2026-119977 applies to it. If it does, we can fix it and record the work in a security logbook for your site.

Ask us if this applies to you Get these alerts by email

Or call +61 2 9043 1246. Monthly plans, no minimum term.