WordPress CVE-2026-119977: Patch the Upgrade Race RCE

Scope. This post is based on the CVE record published by Wordfence (the CNA), the CISA KEV entry and CISA’s SSVC assessment, the WordPress 7.1.4 release notes, and a diff we ran of the WordPress 7.1.3 and 7.1.4 source files. The exploitation telemetry is Wordfence’s, as reported by The Hacker News. We did not reproduce the attack.

What the vulnerability is

The CVE record’s description says: “WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3. This is due to predictable, web-accessible staging paths used during full-package core upgrades. This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window.”

The attack complexity is High for a reason: the attacker has to hit files that exist only while a core update runs. According to The Hacker News’s summary of Wordfence’s analysis, exploitation needs a full-package update that includes the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time before WordPress deletes the temporary files. The same report says attackers have been repeatedly polling paths such as setup-config.php.

“Automatable: no” in the SSVC entry does not make this low priority. It reflects the narrow timing window, not the impact. Combined with active exploitation and total technical impact, it still puts the CVE near the top of a queue; our SSVC guide shows how your own mission and exposure values turn those three into a decision, and every public WordPress site is internet-facing.

Fixed versions

WordPress released 7.1.4 on 28 October 2026 and says: “Because this is a security release, it is recommended that you update your sites immediately.” The release fixes this issue (“A race condition during core updates that could lead to remote code execution reported by Umut Bayram”) along with 21 other listed items.

The CVE record lists 25 affected branches, each with an inclusive upper limit (lessThanOrEqual). We checked each against the backport list in the release notes; in every branch the fixed release is the next point release.

WordPress adds that backports are “a courtesy” and that “only the most recent version of WordPress is actively supported.” Sites on 4.6 or earlier get no fix at all.

What changed in 7.1.4

We fetched wp-admin/includes/class-wp-upgrader.php and wp-admin/includes/update-core.php from the 7.1.3 and 7.1.4 tags of the WordPress/WordPress GitHub mirror and diffed them. Three changes stand out.

1. The staging folder name becomes unguessable. In 7.1.3, unpack_package() names the working directory after the downloaded package file: $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' ), inside wp-content/upgrade/. In 7.1.4 a new get_working_dir_name() appends '-' . wp_generate_password( 16, false ).
2. The upgrade folder can no longer be listed. 7.1.3 deletes everything in wp-content/upgrade/ before unpacking. 7.1.4 skips index.php during that cleanup and writes one if missing, with a comment that the directory “is web-served” and must not be listed “so the name of the working directory created below cannot be discovered from a directory index.”
3. A staged wp-config.php is never copied into the live site. update_core() in 7.1.4 adds wp-config.php to the list of files it skips when copying the new release over the old one, with the comment “Never copy a wp-config.php, which could have been written to the working directory.”

Read together, the fix closes both halves of the race: finding the staged copy, and turning a file written into it into something that persists after the update. That is our reading of the diff; the CNA’s own advisory is the authority on the exploit chain.

Why the update itself is the risky moment

The vulnerable step runs in the code that is already installed. When WordPress updates core, Core_Upgrader::upgrade() calls unpack_package() from the running version’s WP_Upgrader class, and only then copies the new release’s update-core.php into place and runs it. So updating a 7.1.3 site to 7.1.4 stages the 7.1.4 package with the 7.1.3 naming and cleanup logic. The new wp-config.php skip does apply during that update, because it lives in the new update-core.php, but the staging folder is still predictable and listable for that one run.

Two practical consequences:

• Block the staging path before you update, not after. A web server rule that refuses every request under /wp-content/upgrade/ removes the public half of the race. WordPress writes to that folder through the filesystem, not over HTTP, so it should not need web access to it.
• Do not rely on a rule file inside wp-content/upgrade/. Affected versions delete everything in that folder before unpacking, so a .htaccess placed there is gone when it matters.

Illustrative configuration (we did not test these against a live site; adapt paths for subdirectory installs):

# nginx, inside the WordPress server block
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Apache, in the site's root .htaccess or vhost (mod_alias)
RedirectMatch 403 ^/wp-content/upgrade/

Also check whether automatic updates already did the work. In 7.1.4’s Core_Upgrader::should_update_to_version(), the minor auto-update setting reads get_site_option( 'auto_update_core_minor', 'enabled' ), so minor (security) releases install automatically unless the WP_AUTO_UPDATE_CORE constant, a filter or that option turns them off. Many sites will have moved to their branch’s fix on their own; managed hosts and fleets that disable auto-updates will not have.

What to do this week

1. Inventory versions. On each site, wp core version (WP-CLI) or wp-includes/version.php gives $wp_version. Anything at or below its branch’s “last affected” row above needs the update. Anything on 4.6 or earlier needs a migration plan.
2. Block /wp-content/upgrade/ at the web server, reload, and confirm with a request that it returns 403.
3. Update to 7.1.4, or to your branch’s fixed release if you cannot move to 7.1 yet.
4. Check for leftovers. CISA marks this entry for forensic triage. At minimum:

# Run from the WordPress root. Illustrative; adapt the log path.
wp core verify-checksums                 # core files that differ from the release
ls -la wp-content/upgrade/               # should be empty apart from index.php after 7.1.4
find . -name 'wp-config.php' -not -path './wp-config.php'   # unexpected copies
grep -E '/wp-content/upgrade/' /var/log/nginx/access.log* | grep -v ' 403 '

Requests to /wp-content/upgrade/.../setup-config.php or install.php that did not get a 403, especially close to the time of a core update, are the lead to follow. Look for PHP files that verify-checksums does not explain, new administrator accounts, and changes to wp-config.php since the update.

5. Record the decision. If you track patch decisions as tickets, this is a KEV entry with active exploitation and total technical impact on internet-facing hosts; our vulnerability prioritization workflow shows how to carry those signals into the ticket, and the KEV JSON feed guide explains the dueDate and forensicTriage fields.

Limits of this article

• We did not reproduce exploitation. The preconditions and the 62,969-attack figure come from Wordfence via The Hacker News; we could not retrieve Wordfence’s own advisory page in this run.
• Which update package a given site downloads (full, no-content or partial) depends on what the WordPress update API offers it; we did not test which update paths stage the installer files.
• The web server rules are illustrative and untested; test them on a staging site first.

Sources and verification

WordpressCve-2026-119977KevRceRace ConditionPhpPatch Management