CVE-2026-119977 in WordPress: attackers are racing the core update for code execution

Updating WordPress is supposed to close holes. With CVE-2026-119977 it briefly opens one: while a vulnerable site installs a full core package, an unauthenticated request that arrives at the right second can end in code execution on the server.

The flaw affects versions 4.7 to 7.1.3 and was fixed on 28 October in WordPress 7.1.4. On 3 November CISA added it to its Known Exploited Vulnerabilities (KEV) catalogue, The Hacker News reported, and since patch day Wordfence has been logging automated traffic that polls sites again and again in the hope of catching an update mid-flight.

How did the flaw go from patch to KEV listing in six days?

Pieced together from WordPress, Wordfence and CISA data, the timeline runs as follows:

• 28 October. WordPress released 7.1.4 with 22 security fixes, among them a race condition in the core updater reported by researcher Umut Bayram. Patched builds for the older branches shipped alongside it.
• Same day. Wordfence spotted the first probes and had a firewall rule out about three hours after the release, according to webhosting.today.
• 30 October. Wordfence had blocked 62,969 attacks in 24 hours, The Hacker News reported. Previdian's honeypots caught three attempts that day from a UK-geolocated IP address.
• 31 October. Wordfence assigned the identifier CVE-2026-119977 and a CVSS score of 8.1.
• 3 November. CISA listed it in the KEV catalogue, giving US federal civilian agencies until 6 November to remediate.

That three-day window matches the shortest deadline in the new federal patching model we looked at in our piece on CISA's BOD 26-04. For a European company it is a sensible yardstick when an asset faces the internet and the flaw is already being exploited.

Wordfence's numbers count blocked attempts, not breaches, and the company has not reported a successful compromise, according to Techaeris. A separate Wordfence count put requests to the staging paths at more than 18,500 in the 21 hours after its rule went live; on 4 November it cited 12,632 attempts blocked over the previous day. These are different windows and should not be added together. CISA, for its part, has not said what evidence led it to list the flaw.

What actually happens during the update?

When WordPress installs a full core package, it first unpacks it into a working directory under wp-content/upgrade/ and then copies the files into place. Patchstack's analysis shows that, before 7.1.4, three things lined up:

• The working directory had a predictable name.
• The clean-up step deleted the index.php file that stops the folder's contents being listed.
• The staged copy contained wp-admin/setup-config.php, the installation wizard, which can run without the site's configuration.

If the web server serves and executes PHP from that path, whoever requests the wizard at the right moment finds a working installer sitting outside the production install, and from there can reach code execution. In Wordfence's lab the window stayed open for only seconds. Hence the shape of the traffic: patient, repetitive polling. The two busiest sources spent about 14.5 hours working through small groups of sites.

According to Patchstack, the vulnerable code originates in WordPress 2.8. The fix appends 16 random characters to the directory name, keeps the index.php in place and stops configuration created in the staged copy from being promoted into the live install, which Patchstack describes as no longer copying wp-config.php out of the working directory.

Why can a PHP-based firewall not stop it?

In their default mode, security plugins that filter requests from inside WordPress are blind to this attack. The malicious request goes straight to a PHP file in the staged copy without loading the site's WordPress first, so an application-level WAF never gets to run. Wordfence covers it only through its Extended Protection mode, which intercepts direct requests to PHP files. An effective block has to sit in the web server, the reverse proxy or the CDN.

Who is exposed, and why do the severity ratings disagree?

Every release from 4.7 to 7.1.3 is affected, according to the project's advisory and Rapid7's entry. Wordfence lists four conditions for a successful attack: a full-package update that includes the installer files, a staging tree reachable over the web with PHP enabled, a path that is predictable or discoverable, and an attacker who arrives before WordPress deletes the temporary files.

Turning on automatic updates does not shut the window; on an unpatched site it reopens it. Patchstack points out that every update on an unpatched site, unattended ones included, recreates the staging directory.

How serious the flaw is depends on whom you ask, and the disagreement is telling:

Wordfence and Patchstack are scoring how hard a single attempt is to land; WordPress does not explain its rating. CISA is answering a different question, namely whether anyone is trying in earnest. An attacker who can retry for hours at almost no cost turns high complexity into a test of patience. Weighing observed exploitation against exposure, as models that combine KEV, EPSS and SSVC do, therefore produces a better patching order than CVSS on its own.

Two groups need particular care. Sites on 4.6 or earlier fall outside the advisory because they no longer receive security releases; since the vulnerable code dates back to 2.8, they are best treated as exposed. And in many organisations the WordPress estate is far larger than the corporate website: campaign microsites, brand blogs built by agencies, staging environments published by mistake. These are the sites nobody updates by hand, and the ones that tend to surface during an attack surface review.

On managed hosting, exposure hinges on whether the provider already blocks the path for every customer. Ask, and get the answer in writing.

How can you tell whether someone used the window?

The primary signal lives in web server logs: requests for PHP files under wp-content/upgrade/, especially setup-config.php. A simple search across nginx access logs, compressed ones included:

zgrep -E '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log*

Hits on their own prove little, because most will be probes that arrived outside the window. What matters is lining up their timestamps and response codes against the core update history. A 200 response for a PHP file in that folder, coinciding with an update, is enough to open an investigation.

Inside WordPress, the indicators of compromise flagged by Wordfence and The Hacker News are unfamiliar administrator accounts, plugins nobody installed and unexplained PHP files. WP-CLI checks them in minutes:

wp core version
wp core verify-checksums
wp user list --role=administrator --fields=ID,user_login,user_registered
wp plugin list --fields=name,status,version
find wp-content -name '*.php' -newermt '2026-10-28' -not -path '*/cache/*'

If anything looks wrong, treat the site as compromised. Isolate it, preserve logs and a copy of the file system before cleaning, and rotate the database credentials and the keys in wp-config.php, which an attacker with code execution will have been able to read. From there it is an incident response job, and a hasty reinstall wipes out exactly the evidence investigators need.

Which version should you install, and what if you cannot update today?

WordPress has shipped the fix for every branch back to 4.7. Only 7.1 is actively supported; the others receive fixes as a courtesy. The release notes show that the older the branch, the fewer of the 22 flaws affect it:

Older branches rely on that courtesy rather than on active support, so 7.1.4 is the sensible target. Sequence matters too. If updating opens the window, close the window before you press the button.

Patchstack recommends denying web access to wp-content/upgrade/ and checking that the directory cannot be listed. Alex Thomas of Defiant, the company behind Wordfence, agreed in comments to Techaeris that blocking it at the server or CDN before updating is the better sequence. In nginx:

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

In Apache, use an .htaccess file inside that directory or an equivalent block in the site configuration:

Require all denied
Options -Indexes

Between updates the folder should contain only an index.php. Hosting providers can apply the rule to every site on a server at once, which also shields sites that have not yet updated. Wordfence is clear that this reduces exposure without replacing the patch. It is the kind of hardening that belongs in every WordPress server template, CVE or no CVE, and a check that fits naturally into a vulnerability management programme.

Version 7.1.4 also refreshes the root certificates bundled with WordPress after the eMudhra revocation, which we covered when discussing weak keys at a certificate authority.

What should defenders watch over the coming days?

Two dates matter: 6 November, the federal deadline, and 27 November, when the Wordfence rule reaches free-tier users after the usual 30-day delay. The risk itself has no expiry date, because every unpatched site exposes itself again at its next full core update.

Check, too, that automatic updates really did apply. A site configured to update itself that still reports 7.1.3 is precisely the target the probes are looking for.

Update machinery has been part of the attack surface for a long time. Back in 2016, Wordfence described a flaw in WordPress's update infrastructure that could have pushed code to roughly a quarter of the web. This year has brought tampered updates in AOMEI Backupper and backdoors on WordPress sites that were fully up to date. Patching is still the main line of defence. The routine that installs each patch, though, should get the same scrutiny as the code being fixed.

The configurations and commands in this article are for guidance and should be tested in a staging environment before being applied to production systems. Exploitation data comes from WordPress, Wordfence, Patchstack and CISA as published up to 5 November 2026 and may change as further details emerge.