WordPress 7.1.4 fixes an upgrade flaw attackers are already probing

WordPress 7.1.4, released on 28 October 2026, is a security release. It fixes a serious weakness in the way WordPress updates itself, and attackers started probing for it the same day. Most sites will already have updated automatically, but not all do, so it is worth taking two minutes today to confirm that yours has.

What has been fixed

According to Patchstack, WordPress counts 22 vulnerabilities in this release, grouped into 17 advisories. That is a big jump from the seven fixed in 7.1.3 three weeks earlier. WordPress’s own release post lists 13 items and does not give a total.

Almost all of these fixes cover problems that need someone to be logged in, usually with at least Contributor access. Most are cross-site scripting issues, where a user with an account can slip malicious code into pages. Those matter, but they are much harder to abuse on a site where you trust everyone who has a login.

Two of the flaws need no account at all. One allowed anyone to view unpublished Customizer changes (draft design changes to the site), though Patchstack says the settings themselves stayed protected. The other is the one this post is about. The release also updates the security certificates bundled with WordPress, because the eMudhra certificate authority has been revoked.

The upgrade flaw in plain terms

The vulnerability, tracked as CVE-2026-119977, affects WordPress versions 4.7 to 7.1.3. It was reported by Umut Bayram.

When WordPress performs a full core update, it unpacks a complete copy of itself into a folder at a predictable address, inside wp-content/upgrade/. That copy includes the setup script, which works without your site’s own settings. For the few seconds the update takes, an attacker who finds that folder in time can run the installer against a database they control. Wordfence says that would let them create an administrator account and upload malicious code, and from there install backdoors, change content or steal data. On a shop, that could mean customer details or a tampered checkout.

Wordfence rates the flaw 8.1 out of 10 (High). The underlying weakness goes back to WordPress 2.8.

The fix in 7.1.4 adds 16 random characters to the folder name, so it can no longer be guessed, and places a blank index.php inside it so its contents cannot be listed. Patchstack says a second change, not mentioned in the release post, stops wp-config.php (the file holding your database details) being copied out.

How worried should you be

The honest answer is: take it seriously, but there is no reason to panic.

The window is tiny. Wordfence found it lasted only seconds in its tests and describes a successful attack as “difficult in practice”. Patchstack goes further and says it “would not call it practical to exploit”. The catch is that it needs no account and no action from anyone at your business, and the window reopens on every update, including automatic ones.

Attackers are trying anyway. Wordfence saw a handful of attempts on 28 October, then a surge from 29 October to 1 November, peaking on 30 October with more than 74,000 attempts blocked. By 5 November it had blocked more than 240,000. Wordfence is clear that these numbers do not mean many sites have been hacked; most are likely automated requests hoping to catch a site mid-update.

Wordfence also reports that the US Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its list of known exploited vulnerabilities on 2 November 2026. We have not been able to confirm that on CISA’s own page. No public report we have seen confirms a specific site being compromised this way.

How to check your site is patched

Don’t assume the update has happened. Log in to WordPress and go to Dashboard → Updates. It will show which version you are running.

If you are on the current 7.1 branch, you should see 7.1.4. If your site is on an older branch, Wordfence lists these as the fixed versions:

• 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18
• 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31
• 4.9.35, 4.8.34, 4.7.39

There is one point of uncertainty here. Patchstack and Wordfence say these older-branch fixes came out on the same day as 7.1.4. WordPress’s own release post said they were “in progress and will ship as they become ready”, and also notes that only the newest version is actively supported. If your site is on an older branch and Dashboard → Updates doesn’t show the fixed version above, treat it as unpatched. Sites on WordPress 4.6 or older get no fix at all, according to Patchstack.

What you should do

If we look after your website, you don’t need to log in and update anything yourself. If you would like confirmation of exactly which version your site is running, just ask and we will tell you.

If you manage your site yourself:

• Check Dashboard → Updates today. If 7.1.4 (or your branch’s fixed version) isn’t installed, update now using “Update Now”.
• Be aware that updating to the fix runs the old, vulnerable process one last time. Wordfence still advises updating now rather than waiting. As an extra precaution, ask your host to block access to PHP files in /wp-content/upgrade/ before you update.
• Ask your host to confirm that the /wp-content/upgrade/ folder can’t be browsed from the web.
• Review who has Contributor access or higher, and remove accounts that are no longer needed. This reduces your exposure to the other fixes in this release.
• If your site is on an old branch, plan a move to 7.1.4. WordPress 7.2 is due on 8 December 2026, so this is a good moment to get current.

A note on security plugins: Patchstack says plugins that run inside WordPress cannot block this attack, because it bypasses WordPress entirely; it has to be stopped at the web server. Wordfence can block it only if its firewall is set to “Extended Protection” mode. Its paid customers received the rule on 28 October; free users get it on 27 November 2026. Updating is the real fix.

Signs something may be wrong

Wordfence suggests looking for requests to PHP files under /wp-content/upgrade/ in your server logs, particularly setup-config.php. Other warning signs are leftover files in that folder, or plugins and administrator accounts you don’t recognise. Your host can help you check the logs. Clean logs don’t prove a site wasn’t compromised, so if anything looks unfamiliar, get it looked at properly.

Keeping WordPress core, plugins and themes updated and checked is exactly what our care plans are for, if you would rather not have to think about releases like this one.