Attackers are polling WordPress sites to catch the seconds-long update window in CVE-2026-119977

For a few seconds during a WordPress core update, a self-hosted site can be taken over by anyone who knows where to knock. The flaw, CVE-2026-119977, affects WordPress 4.7 through 7.1.3 and is fixed in 7.1.4 and matching branch releases. CISA added it to its Known Exploited Vulnerabilities catalog on November 3, 2026. The awkward part: the update that installs the fix can open the same window, so block one folder before you update.

What happened, in plain English

When WordPress updates itself, it does not overwrite the live site straight away. It first unpacks the new version into a working folder, wp-content/upgrade/, then copies the files into place and deletes the working copy. For a few seconds, a complete second copy of WordPress sits in that folder.

That second copy includes the installer, setup-config.php — the page you see when setting up a brand-new site. The temporary installer looks for the site's configuration file in the wrong places, does not find it, and concludes that WordPress has not been set up yet. So it offers to set it up, without asking anyone to log in.

According to the researcher's write-up, an attacker who reaches that page in time can write a new configuration pointing at a database they control. The update then copies that configuration over the real one. From there the attacker creates an admin account and, on a typical site, uploads a malicious plugin to run code on the server.

Think of a shop that moves its stock through a back room during deliveries: for a few minutes the back door is open and the alarm is off. The trick is knowing when the delivery happens — and attackers solve that by simply standing at the door all day.

The window is short. The CVE record scores it 8.1 out of 10 with high attack complexity, and Wordfence reported the folder was typically reachable for only seconds in lab tests. That is why the attacks look the way they do: automated, repeated requests to the places a staged installer might appear, waiting for an update to start.

Are you affected? What to do now

You are affected if you run self-hosted WordPress 4.7 to 7.1.3. The fix is in 7.1.4, released October 28, 2026, and in matching releases for older branches — for example 7.0.8, 6.9.11, 6.8.12, 6.7.11 and so on down to 4.7.39 (full table on WordPress.org). WordPress 4.6 and older received no fix.

Before you update:

• Block web access to wp-content/upgrade/. This is the step that protects you during the update itself, including the update to 7.1.4, which still runs the old, unpatched unpacking code. On Apache, add this to the root .htaccess, above the WordPress block:

  RewriteEngine On
  RewriteRule ^wp-content/upgrade/ - [F,L]
  

  On Nginx, inside the server block: location ^~ /wp-content/upgrade/ { deny all; }
• Confirm it works. curl -I https://your-site.com/wp-content/upgrade/ should return 403 Forbidden. Check that the directory is not listable either.
• Don't treat WP-CLI as a safe alternative. Per the researcher, wp core update uses the same staging path. A manual update (unpack the new version on your own machine and upload the files, keeping wp-content and wp-config.php) avoids the web-reachable folder entirely.

Update and verify:

• Update to 7.1.4 or your branch's fixed release, then confirm the version in Dashboard > Updates or with wp core version.
• If you rely on automatic background updates, check that they actually completed rather than assuming — and note when they ran. Most sites with default settings will have updated themselves around October 28–29.
• Keep the wp-content/upgrade/ block in place afterwards. It costs nothing.

Then look back:

• Review web server logs around every core update since October 28 for requests to setup-config.php or other PHP files under wp-content/upgrade/.
• Check for administrator accounts you don't recognize, plugins you didn't install, unexpected PHP files, and a wp-config.php with a changed modification date or database host. Belgium's CCB has stressed that patching "does not remediate historic compromise."
• Sites with auto-updates turned off, sites managed by an agency or forgotten on old hosting, and anything on 4.6 or earlier deserve the closest look.

The expert view

This is a time-of-check/time-of-use race (CWE-367), but the more useful way to see it is as a trust-boundary mistake in a deployment pipeline. The updater built a fully functional copy of the application inside the document root, where PHP executes, and assumed nobody would reach it before cleanup. The staged installer then made a second bad assumption: that a missing configuration file in its own directory meant an unconfigured site. Each decision is defensible in isolation; together they hand an unauthenticated visitor the most privileged operation WordPress has.

Predictability is what makes it exploitable. Per the researcher, versions 4.4 to 5.8 used a random suffix on the staging folder and are only conditionally exploitable; from 5.9 onward the folder name is derived from the package filename again and can be guessed. The 7.1.4 fix closes the copy step — the updater no longer carries wp-config.php out of the working directory — which is why the first update to 7.1.4 is still a risk window but a reduced one.

The exploitation picture needs careful reading. Wordfence recorded more than 18,500 requests to staged installer paths in the first 21 hours after disclosure, and described two sources that "repeatedly polled small groups of sites for roughly 14.5 hours" — classic behaviour for an attacker waiting on a race. CISA listed the flaw in KEV "based on evidence of active exploitation," and Belgium's CCB said on November 3 that it is being actively exploited. But as of the reporting we could find, neither CISA nor Wordfence has published details of a confirmed successful takeover, and Patchstack has called the attack impractical. All three can be true at once: a hard-to-win race, run at internet scale against millions of sites, only needs to succeed occasionally. Auto-updates are both the mitigation and the exposure — they moved most sites to safety within a day, and every one of those updates was itself a window.

The AI angle is in the discovery. The researcher, Umut Bayram of Picus Security, writes that he found the flaw in about four hours using "GPT 5.6 Sol as my research partner." The same WordPress release credits Anthropic with two further, unrelated fixes. Bugs that depend on reasoning across several files and a timing assumption — the updater, the copy routine and the installer each behaving reasonably on its own — are the kind that model-assisted review is starting to surface in mature codebases, including ones as heavily scrutinized as WordPress core.

Official sources

• CVE-2026-119977 — CVE Program record, assigned by Wordfence: affected ranges per branch, CVSS 3.1 8.1, CWE-367, CISA KEV entry (added November 3, 2026)
• WordPress 7.1.4 — WordPress.org release announcement, October 28, 2026
• Version 7.1.4 — WordPress.org: full security fix list and fixed version for every branch
• CISA Known Exploited Vulnerabilities catalog — federal remediation deadline November 6, 2026
• CVE-2026-119977: When Updating WordPress Becomes the Vulnerability — Umut Bayram, Picus Security (discoverer's technical write-up, mitigations)

Coverage: Rescana (summary of Wordfence, Patchstack, CCB and CISA statements); SOC Prime (detection guidance). Wordfence's own analysis was not reachable from our side; its figures are cited via that coverage.