CVE-2026-119977: WordPress 7.1.4 Update Can Still Expose RCE

Installing the WordPress 7.1.4 security fix can itself leave older sites open to remote code execution, according to new research from Xint, which also traced the update race condition behind CVE-2026-119977 back to WordPress 2.7.

CVE-2026-119977 is an unauthenticated race condition in the WordPress core updater, scored 8.1 on the CVSS scale by Wordfence, the CVE numbering authority that assigned it. An attacker with no account who hits the seconds-long window while WordPress unpacks a complete update package can run PHP on the server. WordPress lists versions 4.7 through 7.1.3 as affected.

This is not a second bug. Xint’s write-up covers the same flaw that WordPress fixed on October 28 and credits Umut Bayram of Picus Security, and its new detail arrives as CISA lists the bug as exploited. CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, with a November 6 deadline for US federal agencies.

As of November 4, fixed releases exist for every branch from 4.7 to 7.1. Branches 2.7 through 4.6 have no official fix, and no confirmed site compromise has been publicly reported.

How the WordPress Update Race Works

Through version 7.1.3, WordPress unpacked a core update into a folder under wp-content/upgrade/ and named it after the public ZIP file, so anyone could work out the URL in advance. That folder sits inside the web root on a standard Apache and PHP setup, and PHP files placed there can be requested directly.

A complete update package includes wp-admin/setup-config.php, the installer that accepts database settings without a login. The installer only refuses to run when it finds a wp-config.php beside it, and the freshly unpacked copy has none. An attacker who reaches it can submit settings for a database they control, and the installer writes a new wp-config.php into the temporary folder.

Before the fix, the updater read that folder again just before copying files into the live site, so the attacker’s configuration replaced the real one. The live site then ran on the attacker’s database, where an administrator account was already waiting. Xint reproduced the chain on an official update from 7.0.4 to 7.1.3, in both automatic and manual modes, by logging in with that account, uploading a plugin and executing PHP as www-data.

The window lasts seconds, but Xint says repeated requests can start when an update is announced and keep running for days until an administrator clicks Update Now. The attack needs no site account, SSH access, stolen database credentials or compromise of WordPress.org.

The WordPress fix adds 16 random characters to the temporary folder name, creates an index.php so the folder can’t be listed to reveal that name, and stops a temporary wp-config.php from being copied into the live site.

Why the First Update to WordPress 7.1.4 Is Still Risky

The random folder name lives inside the new release, but the old code on the server does the unpacking. A site on an unpatched version therefore extracts the 7.1.4 ZIP into the same predictable folder as before. The patch can’t protect the install that delivers it.

Xint tested that transition directly. On an update from 7.0.4 to 7.1.4, the new update-core.php blocked the configuration swap and the live database settings stayed intact. The attacker could still log in to the temporary copy, execute PHP and write a file into the live WordPress directory before cleanup removed the folder.

Exposure depends on which ZIP the updater picks, and not every site gets the dangerous one. Xint checked the official en_US offers on October 29 and found that a manual update from any unpatched release between 2.7 and 7.0.7 to 7.1.4 selects a complete package containing setup-config.php. Automatic security updates within a maintenance branch use a partial package without that file, and sites that finish that update stay protected in later upgrades.

Sites on 7.1 through 7.1.3 also receive a partial package without the installer, but their updater is still unpatched, so a later release could reopen the window if they haven’t reached 7.1.4 by then. A partial package also requires core files that match the official copies, so a modified core or a reinstall can push a site toward a complete package.

WordPress’s advisory does not mention the first-update exposure, and it starts the affected range at 4.7, the oldest branch receiving fixes. Xint’s audit of official release tags places the same structure in every version since 2.7, while Patchstack traces the underlying code to 2.8.

Why WordPress Rates It Low While CISA Lists It as Exploited

WordPress’s advisory, GHSA-4w3m-c66w-69mg, rates the flaw Low and, as of November 4, still reads “No known CVE.” Wordfence’s CVE record scores it 8.1 High with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, which pairs high attack complexity with full impact on confidentiality, integrity and availability. Patchstack also rated attack complexity as high and said it “would not call it practical to exploit.”

Is CVE-2026-119977 Being Exploited?

CISA says yes, though it has not published details of any attacks. Wordfence deployed a firewall rule at 20:30 UTC on October 28, about three hours after the release announcement, and saw its first match nine minutes later. It logged more than 18,500 requests for staged setup-config.php paths in the first 21 hours.

Wordfence’s threat-intelligence entry showed 62,969 blocked attacks over 24 hours. Those are blocked attempts, and not every request used the exact vulnerable path. Two of the largest sources polled small groups of sites for roughly 14.5 hours, which Wordfence’s Alex Thomas said was consistent with trying to catch the upgrade window.

Honeypot operator Previdian recorded three exploitation attempts from a UK-geolocated address on October 30. Wordfence has not reported a successful compromise. Xint’s post describes the attack chain but includes no exploit code, and Cyber Kendra found no public proof of concept for CVE-2026-119977 as of November 4.

CVE-2026-119977 is the third WordPress core KEV listing in four months, after the wp2shell chain (CVE-2026-63030 and CVE-2026-60137) in July and CVE-2026-87902 in September.

What WordPress Admins Should Do Now

Start by checking the installed version with wp core version or under Dashboard, then Updates, because a site restored from an old backup or one with a failed update may not match its auto-update setting. The fix first appears in 7.1.4, 7.0.8, 6.9.11, 6.8.12 and the matching backports down to 4.7.39, all listed in the WordPress advisory. A site already on one of these should run wp core verify-checksums and move on to the log checks below.

A site that hasn’t reached a fixed release should close the window before starting the update. Patchstack advises denying web access to wp-content/upgrade/ at the web server. That means location ^~ /wp-content/upgrade/ { deny all; } on nginx or RedirectMatch 403 ^/wp-content/upgrade/ on Apache, set in the server configuration or root .htaccess, because Patchstack notes that pre-7.1.4 versions empty the folder before each unpack.

Xint also tells administrators on 2.7 through 7.0.7 not to click Update Now until they have applied its pre-update hotfix, and gives the same advice for sites on 7.1 through 7.1.3 facing an update beyond 7.1.4. The script makes the installed updater use a random folder name and backs up the original file. Administrators then reload Apache or PHP-FPM and run the official update. The tool comes from Xint rather than WordPress.org, so check its published SHA-256 digests before running it on production.

Security plugins need a second look. The exploit requests a staged PHP file directly without loading the site’s WordPress, so a firewall running as a normal plugin never sees it. Wordfence users need Extended Protection enabled, and Wordfence Free sites don’t receive the rule until November 27.

To check for compromise, Xint says to search all retained logs for requests below /wp-content/upgrade/, especially repeated POSTs to one URL and non-404 responses around an update. It also lists PHP connections to unknown MySQL servers, changes to wp-config.php, and unexpected administrators, plugins or sessions. Any hit means isolating the server, restoring from a trusted backup and rotating the database password, WordPress salts and API secrets.