WordPress Core Update Flaw CVE-2026-119977: Are You Affected?

Latest confirmed position (4 November 2026)

WordPress released 7.1.4 as a security release on 28 October 2026. Among its fixes is an upgrade-process weakness that could lead to remote code execution during the upgrade window. The WordPress project later published an advisory (GHSA-4w3m-c66w-69mg) on 29 October 2026 describing a race condition during core updates, with patched releases for every branch back to 4.7. That advisory rates it Low and lists no CVE.

The CVE identifier CVE-2026-119977 comes from a separate record. CISA's alert of 3 November 2026 names it as 'WordPress Core Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability' and says it was added to the KEV catalogue on evidence of active exploitation. Third-party summaries of the record say it was published on 31 October 2026 by Wordfence as the CVE Numbering Authority, with a CVSS 3.1 base score of 8.1 (High). We could not load the CVE.org record directly, so treat the score and publication date as secondary until you have checked the record yourself.

CISA's KEV entry gives a due date of 6 November 2026. That deadline applies to US federal civilian agencies under CISA's directives, not to UK businesses, but it is a fair indication of how CISA rates the urgency. The entry lists ransomware use as unknown.

Immediate action: find your WordPress version, update to the fixed release for your branch, and check logs and files for signs of tampering around earlier updates.

Who should check

The WordPress advisory lists every release from 4.7.0 up to the version before each fix as affected. In practice, that means any site running WordPress core older than the fixed releases below. Any WordPress site you run, whether a brochure site, a shop or a client site managed for someone else, is in scope.

The fixed releases for the most current branches are:

• 7.1.x: fixed in 7.1.4
• 7.0.x: fixed in 7.0.8
• 6.9.x: fixed in 6.9.11
• 6.8.x: fixed in 6.8.12
• 6.7.x: fixed in 6.7.11
• 6.6.x: fixed in 6.6.11
• Older branches: the advisory lists backports for every branch down to 4.7.39. Check the WordPress advisory for your exact branch.

What the flaw is and what an attacker needs

When WordPress applies a core update using a complete package, it unpacks the new files into a working folder inside wp-content/upgrade/. According to the WordPress advisory, that folder was predictable and web-served. An unauthenticated attacker who reached it during the few seconds before the files were cleaned up could achieve remote code execution. That is the 'race': check the timing right, and you get in before the door is closed.

Third-party analysis from Ostorlab and Threat Defence adds detail the WordPress advisory leaves out. Both describe the staged package including an installer script (setup-config.php), which an attacker could abuse while it sat in the web-reachable folder. They also describe an attacker-written wp-config.php being carried into the live site by the old update process. This detail is useful but comes from independent write-ups rather than WordPress itself, so we treat it as probable rather than vendor-confirmed.

The practical preconditions are demanding. The attacker must hit the update window, so a site is only exposed while a core update is actually running, and the web server must serve and execute PHP from that folder. This is why WordPress rates it Low and why Wordfence, scoring the impact if the race is won, rates it 8.1 High. Both ratings are defensible. The KEV listing is the stronger signal for prioritising: someone is trying this in the real world.

One consequence follows from the mechanism. The update that installs the fix is itself carried out by the old, vulnerable upgrader, so that update is also exposed. This is our reading of the advisory rather than a vendor statement. If you can block web access to the upgrade folder before you update (see below), do so.

What to do now

Most sites can be fixed in a few minutes through the dashboard. WordPress says sites that support automatic background updates will update on their own, but do not assume yours has: auto-updates are often disabled, and managed hosts differ.

1. Find your current WordPress version. In the dashboard, the Updates screen shows the installed version and whether an update is offered. If you have command-line access to the server, you can run the read-only command shown below from the site's root folder.
   bashCopy

   wp core version

2. If your version is older than the fixed release for your branch, plan the update straight away. Take a restore point first, because core updates occasionally clash with themes or plugins. If you use a managed host with its own backups, check they cover both files and the database.
3. Where you can, block web access to wp-content/upgrade/ at the web server or CDN before you start. WordPress lists no workaround, so this is third-party defence-in-depth advice from Threat Defence and Ostorlab rather than a vendor-approved mitigation. It is a server or CDN configuration change, so ask your host or web administrator if you do not manage the server, and test that a request to that folder is refused.
4. Update from Dashboard, Updates, Update Now, or by downloading the release from WordPress.org. If you are on 7.1.x, the target is 7.1.4. On an older branch, take the fixed release for your branch, or move to the current branch if your plugins and theme are ready for it, since WordPress states only the latest version is actively supported. The update can take a few minutes; stay on the screen until it finishes.
5. Confirm the new version in the dashboard or with the same command as in step 1. Then verify core files with the checksum command shown below. That compares WordPress's own files with the official checksums. It will not catch a rogue wp-config.php or an unwanted plugin, because those are not core files, so move on to the checks in the next section.
   bashCopy

   wp core verify-checksums

If you cannot update immediately

Where an update has to wait for testing, the server-level block on wp-content/upgrade/ is the only interim measure we have seen suggested, and only by third-party analysts. It addresses only this issue, and it should stay until the site is on a fixed release. Do not treat it as a substitute for patching.

Firewall plugins may also add rules, but one analysis notes that a plugin loaded by WordPress may never see a request that goes straight to a staged file. Do not rely on a plugin alone to protect the update window.

If you cannot update or block access and the site matters to the business, take it out of public view until you can. That is a business decision with real cost, but a stalled update on an exploited platform is worth taking seriously.

After patching: look for signs of tampering

Patching does not prove an earlier update was not raced. These checks are most useful for sites that ran a core update between the 28 October release and the date they were fixed, and for any site that ran updates before then. The first two are within reach of a site owner with hosting-panel access; the rest are better handed to your web administrator or host.

• Web server logs: look for requests to PHP files under wp-content/upgrade/, especially ones that returned a success response, and for requests to setup-config.php or install.php outside the normal wp-admin path.
• wp-config.php: confirm it is the file you expect, with the right database settings and a recent modification time that matches your own changes. An unexpected change is a serious red flag.
• Users and plugins: look for administrator accounts or plugins you do not recognise.
• Files: look for unexpected PHP files in uploads, mu-plugins or leftover upgrade folders.
• Server behaviour: the web server process starting shells or making unusual outbound connections.

If you find something

Treat a modified wp-config.php, unknown administrator or unexpected PHP file as a compromise, not a quirk. Take the site offline or restrict it, keep copies of the logs, and do not simply delete the odd file and carry on. Change database and hosting credentials, and the WordPress keys and salts, from a clean machine. Restoring from a backup taken before the suspect update is usually safer than cleaning in place, but then update before you bring it back online. If personal data may have been exposed, UK GDPR breach assessment duties may apply, and that is the moment to involve specialist help.

What we know about exploitation

CISA's KEV listing is credible evidence that exploitation has occurred somewhere, but CISA has not published the details, and we have found no named victims linked to this CVE. A KEV entry does not mean every site that ran the old updater was compromised.

Third-party reports describe a large volume of probing: Wordfence figures quoted by Threat Defence and Ostorlab cover different time periods and differ, so we are not quoting a single number. Those figures count requests its firewall blocked, which are attempts, not successful compromises. One analysis noted that no public proof-of-concept code had been found when it was written, and another noted the CVE was not in KEV as of 31 October. That was before CISA's 3 November addition.

This article will be updated if CISA, WordPress or other credible sources publish new details.