WordPress 7.1.4 Security Update: Fix CVE-2026-119977 Now

Short answer: CVE-2026-119977 is a race condition in the WordPress core update process. While WordPress updates itself, it unpacks the new files into a predictable folder inside wp-content/upgrade/, and that folder can be reached from the web. An attacker who hits it at exactly the right moment can run code on your server without logging in. Every version from 4.7 to 7.1.3 is affected. Update to WordPress 7.1.4 (or your branch’s patched version, such as 7.0.8 or 6.9.11), block web access to wp-content/upgrade/, and check that folder for PHP files you don’t recognize.

Watch the video: https://youtu.be/0qKQvFcwDSY

I run WordPress sites for clients next to my Laravel and Next.js work, and this one is unusual: the dangerous moment is the update itself. Here is what is known and what to do.

What happened: the timeline

Date (2026)	What happened
October 28	WordPress 7.1.4 released with the fix, backported to every branch back to 4.7
October 29	WordPress publishes advisory GHSA-4w3m-c66w-69mg. Wordfence reports 62,969 blocked attack attempts in 24 hours, the first one nine minutes after its firewall rule went live
November 3	CISA adds CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog. US federal agencies must patch by November 6

An honest note on the numbers: 62,969 is the number of attempts Wordfence blocked, not the number of hacked sites. Wordfence reported no confirmed successful compromise in that window. Winning the race is hard, but attackers are clearly trying at scale.

How the attack works

The official advisory says it plainly: “During a core update that uses a complete package, WordPress extracted the new files to a predictable directory inside the web-served upgrade folder. An unauthenticated attacker who wins a race against that extraction could reach remote code execution.”

In practice:

Your site starts a core update (manually or through auto-updates).
WordPress unpacks the new release into a folder under wp-content/upgrade/ with a name an attacker can guess.
For a short moment, those PHP files sit in a folder the web server will serve.
Bots keep requesting that path. If one lands during the window, PHP runs code outside the normal WordPress request, so it never passes through your plugins.

That last point matters: a security plugin may never see this request, because it hits the unpacked copy directly.

Severity: Low or High?

The two main sources disagree, and the video shows both:

WordPress rates the advisory Low, because the timing window is hard to hit.
Wordfence, which assigned the CVE, scores it CVSS 3.1 8.1 (High), because success means unauthenticated code execution.

CISA’s KEV listing settles the practical question: it is being exploited, so patch it now.

Affected and patched versions

Branch	Affected	Patched
7.1	7.1.0 to 7.1.3	7.1.4
7.0	7.0.0 to 7.0.7	7.0.8
6.9	6.9.0 to 6.9.10	6.9.11
6.8	6.8.0 to 6.8.11	6.8.12
6.7	6.7.0 to 6.7.10	6.7.11
6.6	6.6.0 to 6.6.10	6.6.11
6.5	6.5.0 to 6.5.13	6.5.14
6.0 to 6.4	all	6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18
5.x	all	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.7 to 4.9	all	4.9.35, 4.8.34, 4.7.39

Fix it in three steps

1. Update WordPress

Go to Dashboard > Updates and install 7.1.4 (or your branch’s patched release). With WP-CLI:

wp core update
wp core version   # should print 7.1.4 (or your branch's patched version)

Minor security releases usually install automatically, but don’t assume it. Check every site you manage.

2. Block web access to the upgrade folder

WordPress writes to this folder through the filesystem, so blocking it on the web server does not break updates.

Nginx (inside your server { } block):

location ^~ /wp-content/upgrade/ {
    deny all;
}

Apache (in the site’s root .htaccess, above the WordPress rules):

RedirectMatch 403 ^/wp-content/upgrade/

Reload the server, then test: curl -I https://your-site.com/wp-content/upgrade/ should return 403.

3. Look for files you don’t recognize

find wp-content/upgrade -type f -name "*.php" -newermt "2026-10-28" -ls

After a finished update this folder should be empty or hold only temporary folders. If you find a PHP file you didn’t put there, treat the site as hacked: take a backup for evidence, rotate passwords and keys, scan the whole site, and restore from a clean copy if needed.

For Arabic WordPress sites

Arabic WordPress (the ar language pack) runs the same core code, so it has the same bug and gets the same fix. There is no regional delay for sites in Saudi Arabia or the Gulf. If your dashboard is in Arabic, the path is لوحة التحكم ← التحديثات.

FAQ

Is my site hacked if I was on an old version?
Not necessarily. Most attempts fail because the timing window is short. Check wp-content/upgrade/ for unknown PHP files and review your access logs for requests to that path.

Does blocking wp-content/upgrade/ break updates?
No. WordPress writes there directly through the filesystem; nothing needs to download from that URL.

Will my security plugin protect me?
Not reliably. The malicious request hits the unpacked files directly, so it may never reach your plugin. Use the web server rule.

Why does WordPress say Low while CISA lists it as exploited?
WordPress rates how hard the bug is to exploit. CISA lists bugs with evidence of real attacks. Both can be true.

Related guides

Watch the video: https://youtu.be/0qKQvFcwDSY

Sources

WordPress advisory GHSA-4w3m-c66w-69mg: https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg
BleepingComputer: https://www.bleepingcomputer.com/news/security/cisa-flags-wordpress-rce-flaw-as-actively-exploited-in-attacks/
Security Affairs: https://securityaffairs.com/202394/security/u-s-cisa-adds-wordpress-flaw-to-its-known-exploited-vulnerabilities-catalog-2.html
The Cyber Express: https://thecyberexpress.com/wordpress-vulnerability-7-1-4-patch-attacks/