A flaw in the way WordPress updates itself is now confirmed as actively exploited. The United States Cybersecurity and Infrastructure Security Agency, CISA, added CVE-2026-119977 to its Known Exploited Vulnerabilities catalogue on 3 November 2026, six days after WordPress shipped the fix. Security firm Wordfence, which assigned the CVE number, says its firewall has blocked more than 240,000 exploit attempts, with the heaviest day, 30 October, seeing over 74,000 blocked in 24 hours.

The vulnerability is a time-of-check time-of-use race condition, tracked as CWE-367, in WordPress Core versions 4.7.0 through 7.1.3. Wordfence scores it 8.1 out of 10, rated High. It needs no account on the target site and no trick played on a user: an attacker only has to reach the site while a core update is running.

How the upgrade window opens

A full-package core update downloads the new release and unpacks it into a folder under wp-content/upgrade. In affected versions that folder name was predictable, because it was taken from the package file name, and because wp-content is served by the web server, the unpacked files could be reached over the web while the update was in progress.

The researcher who found the flaw, Umut Bayram of Picus Security, showed that the temporary copy includes the WordPress installer, setup-config.php. That installer checks only two places for an existing configuration file and cannot see the live site's wp-config.php, so it concludes the site has not been set up yet. An unauthenticated attacker who reaches it during the window can create a malicious wp-config.php inside the temporary copy, pointing the site at a database the attacker controls.

When the update finishes, WordPress copies the staged files over the live installation, and wp-config.php was not on its skip list, so the attacker's file overwrites the real one. The site then connects to the attacker's empty database, exposes its normal installation workflow, and the attacker can create the first administrator account. On a typical single-site installation that administrator can upload a malicious plugin and run arbitrary PHP code on the server.

The fix, and the catch in applying it

WordPress fixed the flaw in version 7.1.4, released on 28 October 2026, with backported releases for every maintained branch down to 4.7, including 7.0.8 and 6.9.11. Versions 4.6 and earlier receive no fix. The patch gives the staging folder a 16-character random suffix, keeps an index.php file in the upgrade folder so the random name cannot be discovered through directory listing, and adds wp-config.php to the list of files never copied during an update.

There is a catch that site owners should know about. The unpacking step of an update runs on the code already installed, so a site updating from 7.1.3 to 7.1.4 creates the predictable folder one last time. Wordfence advises blocking PHP files in the upgrade directory at the web server level before running the update, and checking logs for requests to PHP files under wp-content/upgrade after past updates.

CISA gave federal civilian agencies until 6 November to fix the flaw, a deadline that has now passed, and marked the entry for forensic triage, meaning agencies must also check affected systems for signs of compromise. CISA records known ransomware use as unknown. Wordfence cautions that its blocked count does not mean large numbers of sites were successfully exploited, because an attempt only succeeds if it lands inside the short upgrade window. Even so, this is the fourth WordPress Core entry in CISA's exploited list this year, after two in July and one in September. Site owners should confirm the installed version on every site rather than assuming an automatic update finished, and move any site still on 4.6 or earlier to a supported release.