Racing the Update: Attackers Probe a WordPress Core Flaw That Opens During Patching

What happened

On October 28, 2026, WordPress released version 7.1.4, a security release that fixes 22 vulnerabilities. Most need an authenticated account; the one that stands out is a flaw in how core updates are staged, which needs none. The WordPress security advisory followed on October 29, listing fixed releases for every supported branch from 7.0.8 back to 4.7.39. The issue was found and responsibly disclosed by Umut Bayram of Picus Security. The CVE, CVE-2026-119977, was assigned by Wordfence and published on October 31.

Attackers moved faster than most site owners. Wordfence deployed a firewall rule for its paid customers at 20:30 UTC on October 28, about three hours after the release, and it matched its first request nine minutes later. In the first 21 hours it recorded more than 18,500 requests to staged setup-config.php installer paths. The two largest sources polled small groups of sites for roughly 14.5 hours, waiting for an update to open the window; others tried many variations of staging-folder and version names. Not every request used the exact vulnerable path, but the probing shows attackers understood the race quickly.

The volume peaked and is now falling. The Hacker News reported 62,969 attacks blocked by Wordfence in the 24 hours to October 30; Wordfence's vulnerability record showed 13,835 in the 24 hours to November 3. These counts cover only sites Wordfence protects, so the real number is higher.

TrendAI™ telemetry shows the same pattern. Since our network and server rules for this flaw shipped on October 30 and 31, they have recorded thousands of exploit attempts against customer environments, and the count is still rising. None has led to a confirmed compromise: every endpoint alert we have investigated so far has been a legitimate WordPress or plugin update. TrendAI™ customers can visit this knowledge base entry for information on available solutions and how to mitigate this vulnerability.

How the flaw works

WordPress can update its core files in two ways: a partial package that contains only changed files, or a complete package with the whole release. When it used the complete package, affected versions extracted the new release into a working folder under wp-content/upgrade/ with a predictable name. That folder is inside the web root, so on many servers anyone can request files from it.

The staged copy includes the WordPress installer, wp-admin/setup-config.php. On a live site the installer refuses to run because a configuration file, wp-config.php, already exists. The staged copy has no configuration file, so for as long as the folder exists, its installer will run for anyone who requests it. From there an attacker can point the staged install at a database they control and get code running on the server under the web server's account.

Four conditions have to line up, as Wordfence describes them:

• The site performs a full-package core update.
• The staging folder is publicly reachable and the web server executes PHP in it.
• The attacker knows or guesses the folder path.
• The attacker reaches the installer before WordPress cleans the folder up.

WordPress 7.1.4 closes the gap by randomizing the staging folder name, adding an index guard, and preventing unsafe promotion of staged configuration data, in Wordfence's description. The fix was backported to every affected branch.

Why the ratings disagree

WordPress rates the issue Low; the CVE record rates it High at CVSS 3.1 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Both are defensible. The attack needs no credentials and gives full code execution, which drives the score up. It also needs an update to be running at the moment of the request, and in lab tests that window lasted only seconds. That is why the attack complexity is High and why WordPress sees it as unlikely to succeed against any single site.

What changes the picture is scale, and automatic updates. Most WordPress sites receive security releases through automatic background updates, so they pass through the update window on their own schedule, without anyone watching. One attacker cannot predict when a given site will update, but automated tooling can poll thousands of sites every few seconds and wait. The polling Wordfence saw is exactly that strategy. The odds for any one site are low; across the internet, they are not.

What is known and what is not

What organizations should do

1. If you control the web server, block the staging folder before you update. The update is the moment of exposure, so deny web requests to /wp-content/upgrade/ first. Put the rule in the server configuration, a web application firewall or a CDN rule, not in a file inside that folder (older versions clear the folder's contents during updates, which removes the rule). For example, in nginx: location ^~ /wp-content/upgrade/ { deny all; }; in Apache: RedirectMatch 403 ^/wp-content/upgrade/. If you can't do this quickly, don't wait: update anyway, because 7.1.4 also fixes 21 other vulnerabilities.
2. Update and check the version. Install WordPress 7.1.4 or the fixed release for your branch. Do not assume automatic updates have run: confirm the version on every site, including marketing, regional and campaign sites that fall outside central management. Sites on 4.6 or earlier have no fix and need to be upgraded or taken offline.
3. Look for attempts and their aftermath. Search web server logs for requests to PHP files under wp-content/upgrade/, particularly setup-config.php. A request on its own shows an attempt; a 200 response during an update window is worth investigating. Check for PHP files under wp-content/upgrade/ that you did not put there, unfamiliar administrator accounts and unexpected plugins.
4. Treat a successful hit as a compromise. If an installer request succeeded during an update, assume code ran on the server. Rotate database and administrator credentials and review the site for web shells.

How TrendAI™ can help

• Virtual patching at the endpoint and network: TrendAI™ virtual patching protects against attempts to exploit CVE-2026-119977 inline on the network and at the endpoint, including physical and virtual servers. On the network, TrendAI Vision One™ TippingPoint™ protection was released on 30 October and is on and set to block by default. On the endpoint, TrendAI Vision One™ Endpoint Security protection was released on October 31, and recommendation scans apply it to the servers that need it. It ships in detect mode: switch it to prevent to block attempts while you update.
• Network detection and response: TrendAI Vision One™ Network Security detects exploit requests on the network.
• Detection and response: TrendAI Vision One™ has new detections for enumeration of the upgrade folder and changes to a staged setup-config.php, and more than 90 existing detections for what an attacker would do next on a compromised server, such as web server processes starting shells, web shells written to disk, and persistence through SSH keys.
• Exposure: TrendAI Vision One™ Cyber Risk Exposure Management (CREM) flags vulnerable WordPress installations and helps prioritize which to update first.
• Hunting: Search TrendAI Vision One™ for the detections above on your web servers, and for web requests to PHP files under wp-content/upgrade/.