WordPress Core Vulnerability: Why the 7.1.4 Fix Matters

The newest WordPress core vulnerability sat inside the one feature every site owner is told to trust: the updater. WordPress shipped version 7.1.4 on October 28, 2026, and its release post says a weakness in the upgrade process “can lead to remote code execution during the upgrade window.” The flaw, tracked as CVE-2026-119977, affects WordPress 4.7 through 7.1.3, and attackers started probing for it within minutes of the fix going public, according to The Hacker News and Rescana. Security researchers disagree on how dangerous it really is. Our view is that the debate matters less than the fix, because the fix is cheap: confirm you are on 7.1.4 or a patched branch, and block web access to the folder WordPress uses to unpack updates.

This post covers how the bug works, why the experts rate it so differently, which sites are still exposed, and the two changes that close it.

What the WordPress 7.1.4 Flaw Does

When WordPress installs a full core update, it unpacks the new files into a temporary folder under wp-content/upgrade/ before moving them into place. Before 7.1.4, that folder had a predictable name, and on many servers it could be reached from the web. The unpacked copy includes the WordPress installer, wp-admin/setup-config.php, which Patchstack says “boots on its own without the site’s configuration.”

That creates a race. If an attacker requests the staged installer during the few seconds the update is running, they can interact with that copy and reach PHP code execution, per The Hacker News and Patchstack. No login is needed and no one has to click anything. Patchstack says an attacker who wins the race could run the installer against a database they control, inside the victim’s own web root.

Key facts at a glance

• Tracking ID: CVE-2026-119977, scored CVSS 8.1 (High) by Wordfence, which assigned the CVE, per Rescana and 1Arabia.
• Affected: WordPress 4.7 through 7.1.3.
• Fixed: WordPress 7.1.4, released October 28, 2026, with fixes backported to every branch back to 4.7, per the WordPress release post and Rescana.
• Credit: researcher Umut Bayram reported the flaw, according to WordPress.
• Next major release: WordPress 7.2 is planned for December 8.

The same release fixed a batch of other security bugs, most of them stored cross site scripting issues in the Interactivity API, blocks and the Customizer. Patchstack notes that nearly all of those need a logged in account, usually Contributor or higher, which makes the upgrade race the headline fix in this release.

The Debate: Critical Threat or Lab Curiosity?

Security vendors looked at the same bug and landed in very different places.

Patchstack scored the attack complexity as high and said it “would not call it practical to exploit,” because the attacker has to hit the right path during a window it calls “tiny.” The WordPress release post itself gives no severity score. On that reading, this is a clever bug that very few real attackers will ever win.

Wordfence sees more risk. It rated the flaw 8.1, and The Hacker News reports Wordfence found attackers “repeatedly polling” paths such as setup-config.php. Wordfence deployed a firewall rule on release day and saw the first matching request nine minutes later, per Rescana and InternetSecure. Both report more than 18,500 requests aimed at the vulnerable paths in the first 21 hours. The Hacker News put Wordfence’s 24 hour blocked count at 62,969. These are attempts, and none of the sources report a confirmed break in.

A narrow window is a weak defense against software that never gets bored. Bots can poll a path thousands of times a day for free, and every core update reopens the window.

Both sides have a point. Patchstack is right that the timing is hard and that a single random attempt will almost always miss. Wordfence is right that attackers do not make single attempts. Patchstack also notes the window “returns on every update, including unattended ones,” which means a site that updates on a schedule gives a patient bot a known time to try. We side with treating it as serious. The odds on any one request are low, but the cost of the fix is close to zero, and the cost of losing the race is a full site takeover.

Why Security Plugins Cannot See This WordPress Core Vulnerability

This is the part that should worry site owners who lean on a security plugin. The staged installer runs from its own files in the upgrade folder. It never loads your live WordPress site, so it never loads the plugins that protect it. Patchstack says a PHP level firewall “can’t stop this request” for that reason, and Rescana makes the same point: the malicious request reaches a PHP file directly, so WordPress security plugins may never see it.

We made a similar argument in our post on PHP2Shell. Some threats live below WordPress, and the only controls that reach them are the ones at the web server, the edge network or the host. A plugin that runs inside WordPress can only guard the doors WordPress opens.

Who Is Still Exposed

WordPress says sites that support automatic background updates will start the update on their own. Wordfence expects most sites to get the fix that way, but advises checking that the update actually finished, per Rescana. The sites most likely to still be on a vulnerable build, according to InternetSecure and Rescana, are these:

• Sites with automatic updates turned off, whether by a plugin or by lines such as AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE in wp-config.php.
• Sites deployed with Git or Composer, where the WordPress version is pinned in code and only changes with a new build.
• Sites where the background update failed, for example because the disk was full or file permissions were wrong. These often fail quietly.
• Sites managed by agencies or hosts that hold core updates for testing outside a normal patch process.
• Sites on WordPress 4.6 or older, which get no fix at all.

Security releases are the updates you should not delay

In our Rank Math PRO backdoor post, we suggested holding routine plugin updates for a day or two so a bad package can be caught before it reaches your site. That advice still stands for feature releases. Core security releases are different. They come straight from WordPress.org, the details of the bug are now public, and bots began probing within minutes. A minor core security release like 7.1.4 is the kind of update to apply the same day.

How to Close the Hole Today

There are two fixes and one check, and each protects you in a different way.

1. Confirm you are on a fixed version

In wp-admin, go to Dashboard > Updates and check the version number. A safe result is 7.1.4 or newer, or the latest backport on your branch, such as 7.0.8 or 6.9.11. If you manage many sites, run wp core version with WP-CLI on each one, or check your management dashboard, and do not assume the background update worked.

2. Block web access to the upgrade folder

WordPress unpacks updates through the file system, so nothing legitimate needs to load files in wp-content/upgrade/ over the web. Patchstack and Rescana both recommend denying web access to that folder at the server level. Put the rule in your server or site root configuration, and keep it out of the upgrade folder itself, since WordPress clears that folder.

On Apache, add this line near the top of the .htaccess file in your site root, above the WordPress block:

RedirectMatch 403 ^/wp-content/upgrade/

On NGINX, add this inside the server block for the site, then reload NGINX:

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

Then test it. Open https://yoursite.com/wp-content/upgrade/ in a browser. You should see a 403 Forbidden error and no file list. If you are not comfortable editing server files, ask your host to do it. It takes a minute.

3. Check your logs and admin list

The Hacker News and Rescana both suggest reviewing logs around your last core update for requests to PHP files under wp-content/upgrade/. Also look for admin accounts you do not recognize, plugins you did not install and stray PHP files. Our guide to WordPress site security steps walks through those checks.

What the Patch Changes

WordPress 7.1.4 makes the staging folder much harder to find. According to Patchstack and Rescana, the release:

• Adds 16 random characters to the name of the folder where updates are unpacked, so the path is no longer predictable.
• Keeps an index.php file in the upgrade folder and recreates it if it goes missing, which stops the folder from being listed.
• Stops wp-config.php from being copied out of the working folder during core updates.

One detail is worth knowing. Rescana notes that the update to 7.1.4 itself still runs through the old unpacking code, since the fix only takes effect once the new files are in place. That is one more reason to add the server rule even if your site has already updated.

How WP Farm Thinks About Core Updates

This flaw is a good example of why hosting choices matter for security. The fix that fully closes the gap lives at the web server, a layer most site owners never touch. Every WP Farm plan includes Imunify360 server side malware scanning, daily off site backups and malware cleanup, and the sites we manage run behind Cloudflare. Our team handles updates every day, which means core security releases get applied and checked by people who look at the version number afterward.

If you host elsewhere, ask your provider three questions this week. Is every site on a patched core version? Is web access to wp-content/upgrade/ blocked at the server? If something did get in during an update, how far back do the backups go? Clear answers mean your host is paying attention.

WordPress Core Vulnerability FAQ

Is my site safe if it updated to 7.1.4 automatically?

Your site is no longer exposed to this flaw once it runs 7.1.4 or a patched backport. Confirm the version in Dashboard > Updates, because background updates can fail quietly. If you want extra assurance, review logs around the update time for requests to the upgrade folder.

Will a security plugin protect me?

Not from this bug. The staged installer runs without loading your live WordPress site, so plugins never get a chance to inspect the request. Patchstack and Rescana both recommend blocking the folder at the web server instead.

Does blocking wp-content/upgrade break updates?

No. WordPress moves update files through the file system on the server. The block only stops outside visitors from loading files in that folder while an update is running.

Has anyone been hacked through this flaw?

None of the sources we reviewed report a confirmed compromise. Wordfence has reported thousands of blocked attempts, and the attack details are public, so we treat any unpatched site as at risk.

Check Your Site

Not sure whether your site is patched and locked down? Run a free WP Farm security test to see where you stand. When you want a team that handles core updates, server rules and backups for you, see our managed WordPress hosting.