WordPress CVE-2026-119977: Fix the Upgrade Race Bug

Quick answer

> Patch and investigate. CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog based on active exploitation. Install the fixed WordPress release, restrict public access to the upgrade directory, and check for earlier compromise. A successful update alone is not an all-clear.

What the bug is, in plain English

During a full-package update, WordPress temporarily unpacks core files, including an installer, into a predictable directory under wp-content/upgrade. If that directory is reachable from the web and can execute PHP, an attacker without an account can request the installer at the right moment and reach code execution. Wordfence explains the upgrade race.

Think of unpacking a delivery in a publicly accessible room: the attacker tries to use something before you finish putting it away. Several conditions must align, including winning that timing race. Wordfence describes high attack complexity and a laboratory window normally lasting seconds; repeated automated polling improves the odds. That narrow window is not a reason to leave the bug unfixed.

The patch randomizes the staging directory, adds an index guard, and prevents unsafe promotion of staged configuration data, according to Wordfence.

Am I affected?

Wordfence lists WordPress 4.7.0 through 7.1.3 as affected. Compare your installed version with its branch's fixed release:

The explicit version numbers above come from Wordfence. WordPress says the security fixes were backported through 4.7. Do not assume an omitted branch is unaffected or guess its patch number.

Fix in 10 minutes

Use this as a short action checklist, not a guaranteed completion time. If your host manages core updates or server configuration, give it the same checklist.

Start with a compromise check. Review the indicators below before patching and retain suspicious log entries for investigation. CISA's alert references federal guidance to check for compromise before patching.

Dashboard route: open your WordPress dashboard's Updates screen, apply the core security update, then confirm the installed version against the table. WordPress asks users to update immediately.

WP-CLI route: from the intended site's WordPress directory, use the commands listed by HOL:

wp core update
wp core version
wp core verify-checksums

Check the reported version, rather than relying only on an update-complete message. If you must remain on an older branch, ask your host to install its verified fixed release.

Restrict the staging directory. HOL provides these web-access deny rules. Ask the server administrator to apply the appropriate rule and check that it covers your installation's actual URL path.

For nginx:

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

For Apache, place this outside the WordPress block:

RedirectMatch 403 ^/wp-content/upgrade/

These rules restrict web access to the staging tree. Keep the core patch as the main fix: Wordfence explicitly says a firewall is no substitute for updating.

Check if you were hit

Wordfence recommends reviewing PHP requests under the upgrade directory, unfamiliar administrators, and unexpected plugins or PHP files. Use this illustrative filter on a plain-text access log; replace the placeholder with your log path:

grep -Ei '/wp-content/upgrade/[^ ?"]*\.php([/?"[:space:]]|$)' /path/to/access.log

Review matching requests around earlier core updates. Treat matches as investigation leads, not automatic proof of code execution. Record the requested path and surrounding entries before deciding what happened.

In WordPress, review administrator accounts and installed plugins for anything you do not recognize. Ask the person responsible for maintenance about unexplained additions. Review unexpected PHP files with your host, and run wp core verify-checksums as shown above. Keep unexplained results for investigation rather than declaring the site clean because it now runs a fixed version. HOL stresses that updating cannot reveal whether an earlier upgrade was exploited.

If suspicious changes recur, follow the recovery questions in why your WordPress site keeps getting hacked. For a light external check of headers, TLS and exposed files, use the vulnerability scanner. It cannot confirm that your WordPress core version is patched or detect a past compromise.

Why severity ratings differ: Low, High and KEV

HOL reports that the WordPress advisory rates this Low, while Wordfence rates it High. Wordfence assigns CVSS 8.1 and describes demanding exploitation conditions alongside the possibility of code execution.

The supplied sources do not explain the complete reasoning behind the Low rating. Avoid inventing a reconciliation. KEV answers a different question: CISA confirms exploitation in the wild. For an owner deciding whether to act, that is sufficient reason to prioritize the fix.

FAQ

Can I wait for the next major release?

WordPress says to update immediately. Use an available security release rather than waiting for a major upgrade.

Does a firewall make patching optional?

No. Wordfence says firewall protection can reduce exposure but does not replace patching. Apply the fixed core release and verify it.

Does KEV mean ransomware was involved?

No such conclusion is supported here. HOL lists ransomware use as unknown. Active exploitation and confirmed ransomware use are different claims.

Sources

• CISA: November 3 KEV addition.
• WordPress: 7.1.4 security release.
• Wordfence: upgrade race, affected versions and fixes.
• HOL: update commands, deny rules and severity differences.