WordPress Update Race Condition: Confirm You’re on 7.1.4

WordPress 7.1.4, released October 28, 2026, fixes a WordPress update race condition that lets an unauthenticated attacker run code on a site while a core upgrade is in progress, along with 21 other security fixes. Scanners began probing for that brief window nine minutes after Wordfence shipped a blocking rule, so check that your site actually installed the patched build.

Why is the WordPress update race condition dangerous during the upgrade itself?

The flaw sits inside the update process. It affects WordPress Core 4.7 through 7.1.3, requires no login, and carries a CVSS score of 8.1 (High). Wordfence calls it the “Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution.” No CVE identifier or CVSS vector string had been published at the time of writing, so be skeptical of any CVE number attached to it until WordPress confirms one.

Here is how it works. During a full-package update, WordPress unpacks the complete new release into a staging folder beneath wp-content/upgrade before moving files into place. In affected versions, that folder had a predictable name and was reachable from the web.

The temporary copy includes the WordPress installer, setup-config.php, the script that writes wp-config.php on a fresh install. An attacker who reaches that staged installer while it exists can interact with it and reach PHP code execution.

The window is small. “In lab environments, the vulnerable staging directory normally remained available for only seconds,” Wordfence writes. Several conditions have to line up:

• a full-package update that contains the installer files;
• public web and PHP access to the staging tree;
• a staging path the attacker can predict or discover;
• a request that lands before WordPress cleans up the temporary files.

For a single request, those are long odds. Attackers get around that by polling the same sites repeatedly and waiting for an upgrade to start. So on an unpatched site, the act of patching is itself a short exposure. That is no reason to delay: update promptly, put a firewall in front of PHP, and review what reached the site during the upgrade.

WordPress fixed the bug by randomizing the staging directory, adding an index guard and preventing unsafe promotion of staged configuration data. Umut Bayram reported the issue responsibly, and the WordPress Security Team coordinated the release.

What are scanners looking for under wp-content/upgrade?

Scanners are looking for the staged copy of setup-config.php while an upgrade is running, and they started almost immediately. Wordfence deployed a blocking firewall rule on October 28 at 20:30 UTC, about three hours after the release. “The first match for our new firewall rule arrived nine minutes after deployment,” the company reported.

In the first 21 hours, Wordfence logged more than 18,500 requests targeting staged installer paths. That works out to roughly 881 requests an hour across its telemetry. It is not a per-site rate, and it is not a count of successful attacks.

Two of the largest sources polled small groups of sites repeatedly for about 14.5 hours, which Wordfence describes as consistent with trying to catch the brief upgrade window. Other sources tried many directory names and version strings. Not every request used the exact vulnerable layout, but the ones that did show the operators understood the race. Wordfence did not name or attribute any source, and it documented probing, not confirmed code execution.

For log reviewers, location is what matters. Requests for setup-config.php under wp-admin on an already configured site are routine background noise. Requests for an installer path inside wp-content/upgrade are what this campaign looks like. Because the request goes straight to a staged PHP file, WordPress never loads, so anything that depends on WordPress to see traffic will miss it. This is the same mass scanning we described in how attackers find outdated sites.

Did your site actually install WordPress 7.1.4?

Check rather than assume. Open Dashboard > Updates, or run wp core version --extra from the site root if you have WP-CLI. WordPress published 25 patched point releases covering every branch back to 4.7. You do not have to be on 7.1.4 specifically. You must be on the patched release for your branch.

If your version is lower than the number for your branch, the site is exposed. If you run several sites, check each one individually. A management dashboard that reports “up to date” is only as accurate as its last sync.

Still on WordPress 4.6 or older?

WordPress 4.6 and earlier get no security updates at all. This race starts at 4.7, but those branches have missed nearly a decade of other fixes, and backports for this release stop at 4.7.39. The only remedy is a planned migration:

• Take a full backup of files and database, and confirm it actually restores.
• Clone the site to staging and upgrade there, ideally straight to 7.1.4.
• Check that your PHP version, theme and plugins still work. Abandoned plugins are usually the real blocker.
• Move the upgraded site to production and confirm the version matches the table above.

Until then, remove unused accounts and plugins, put a server-level firewall in front of PHP, and run continuous malware monitoring so a compromise surfaces in hours, not months.

Why automatic WordPress updates may not have run

Automatic background updates usually install security releases, but several ordinary settings can stop them without any warning. WordPress has applied minor and security releases automatically since version 3.7, but that default only holds if nothing overrides it.

Look at these first:

• WP-Cron. WordPress schedules update checks through WP-Cron, which runs when the site receives visits rather than on a system clock. A low-traffic site, or one whose host blocks loopback requests, can sit on a pending update for days.
• DISALLOW_FILE_MODS. Setting this constant to true in wp-config.php blocks all dashboard file changes, including core updates. It often gets copied from hardening guides into production and then forgotten.
• Updater constants and filters. AUTOMATIC_UPDATER_DISABLED, WP_AUTO_UPDATE_CORE set to false, or a plugin filter can switch core updates off.
• Hosting controls. Some managed hosts disable WordPress updates and push releases on their own schedule. Ask yours when 7.1.4 or your branch equivalent was applied.
• File permissions. If the web server user cannot write to core files, the update fails, and Site Health is often the only place that says so.

If any of these apply, update manually now, then decide whether the setting still serves a purpose.

How do you check for compromise after your upgrade window?

Start with the timestamps of your own upgrade, because a probe only matters if it landed while the staging folder existed. Work in this order:

1. Preserve access logs first. Copy them before you clean up any upgrade leftovers or let the host rotate them.
2. Pin down the upgrade window. The automatic update email WordPress sends to the admin address, the host’s update log, or the modification time on core files will give you start and end times.
3. Correlate. Search the logs for requests to installer paths under wp-content/upgrade within that window. Probes outside it are weak evidence. A 200 response inside it is a lead to follow up, not proof of code execution.
4. Look for what an intruder would change. Check whether wp-config.php has changed, and look for new administrator accounts, unfamiliar PHP files in the uploads directory, new or modified plugins and themes, and new cron entries.
5. Run core checksums with wp core verify-checksums. It compares core files against the official release for your version and locale. It says nothing about plugins, themes, uploads or the database.

From our cleanup work: the step owners most often lose is the first one. By the time someone notices a problem, the host has rotated a week of access logs. Default logs also do not record request bodies or PHP execution, so a quiet log is not a clean bill of health.

Do not try to reproduce the race on a live site to “test” it. Interacting with installer scripts can rewrite configuration or take the site down. Use a disposable copy if you need to validate anything.

If you find signs of intrusion, restore from a backup taken before the upgrade window, or reinstall. Then rotate the database password, salts and admin credentials. Replacing core files alone will not remove a backdoor in a plugin or in the database. Our cleanup case studies show how often persistence survives a core reinstall.

No confirmed compromises through this race have been published yet. Until exploitation data appears, any site that upgraded without a firewall in front of PHP deserves a log review for its upgrade window.

Can a firewall cover you until November 27?

A firewall can buy time, but only if it runs before PHP executes the staged file, and it never replaces the patch. Wordfence Premium, Care and Response customers received the rule on October 28. Wordfence Free users get it on November 27, 2026, after the standard 30-day delay, so free-tier sites rely on patching alone for a full month.

Placement is the technical catch. “This exploit directly requests a staged PHP file without first loading WordPress,” Wordfence notes. A security plugin that only loads with WordPress never sees the request. Wordfence’s answer is Extended Protection mode, which runs the firewall before any directly requested PHP file. If you use Wordfence, confirm the firewall shows as optimized.

If you use another product, find out whether it inspects traffic at the server or network edge, before PHP runs. A website firewall that filters traffic before it reaches your server handles this kind of direct-file request regardless of what WordPress is doing.

On servers you control, denying PHP execution inside wp-content/upgrade is a reasonable extra layer. Test it on a staging copy first, because a broken updater leaves you unpatched. Whichever layer you use, as Wordfence itself puts it: “Receiving the rule does not replace installing the security update.”

Which of the other 21 fixes should a small site care about?

Most of the remaining fixes matter only if other people can log in to your site, but two apply to every site. One is an unauthenticated information disclosure that could expose unpublished Customizer changesets, meaning design or content changes you had not published yet. The other is updated bundled root certificates following the eMudhra revocation, which affects how WordPress trusts outbound HTTPS connections.

The rest mostly require an authenticated Contributor, Author or Editor account, and several also need a victim to view attacker-controlled content:

• Stored cross-site scripting in block delimiters, the Categories block, Comments Pagination and Post Navigation labels, Customizer selective refresh, personal data erasure requests, specially crafted usernames, and Image and Playlist block handling.
• Interactivity API issues, including unsafe URL, event-handler, internal-property and object bindings, prototype pollution, Script Module data shadowing, uploaded text-file handling in the Interactivity Router, and a persistent denial of service.
• A Notes REST API authorization gap affecting custom roles that can moderate comments but cannot edit the post a note is attached to.

Stored XSS saves a script in site content, and that script runs in the browser of whoever views it. If an Editor plants it and an administrator opens the page, the script acts with administrator rights.

On a single-login site, the risk is low. On a membership site, a newsroom or an agency build with guest authors, this is a realistic path to account takeover. We covered a related case in Comment2Shell, where a WordPress comment led to server control.

FAQ

Is WordPress 7.1.4 a security update I need to install?

Yes. It fixes 22 Core vulnerabilities, including an unauthenticated race condition that can lead to remote code execution. Sites on older branches need the matching patched point release, such as 6.9.11 or 7.0.8.

Can a WordPress site be hacked while it is updating?

On versions 4.7 through 7.1.3, yes. During a full-package upgrade, a predictable staging folder under wp-content/upgrade briefly holds a copy of the installer, and attackers poll for it. The patched releases randomize that folder and close the gap.

How do I check if automatic updates installed 7.1.4?

Open Dashboard > Updates or run wp core version –extra, then compare the result with the patched release for your branch. If it did not update, check WP-Cron, DISALLOW_FILE_MODS, updater constants and your host's update policy.

Does the free Wordfence plugin block the upgrade exploit yet?

Not until November 27, 2026, after the standard 30-day delay. Premium, Care and Response customers had the rule from October 28. Installing the patched Core release is the actual fix in every case.

Are WordPress 4.6 and older still getting security fixes?

No. Backports stop at 4.7.39, so sites on 4.6 or earlier need a planned upgrade to a supported release, tested on a staging copy first.

If your site upgraded without a firewall in front of PHP and the logs look odd, a second opinion costs little. SiteGuarding can scan, clean and shield your WordPress site while you finish the update and review your upgrade window.