WordPress 7.1.4: updating without exposing your site

12 min

If your site runs on WordPress, an update is waiting for you. For once, the problem lies in the update process itself. WordPress 7.1.4, released on 28 October 2026, fixes 22 security vulnerabilities (Astuces du Web). The most serious one allows an unknown person, without any login credentials, to execute code on your server during the few seconds while WordPress is updating (LeBigData). The first attack attempts were detected a few hours after the fix was released (LeBigData).

The countermeasure is simple. But the order of the steps matters: done in the wrong sequence, they leave the door open one last time.

What WordPress 7.1.4 fixes

Most of the 22 vulnerabilities are so-called XSS flaws: someone slips code into a piece of content, and that code runs in the browser of whoever opens it, often the administrator reviewing a draft (Astuces du Web). Almost all of them require an author account on the site, at least at Contributor level (Astuces du Web).

Two vulnerabilities, however, require no account at all (Astuces du Web):

code execution during the WordPress core update, the most serious one;
access to unpublished drafts in the Appearance > Customize tool, which could reveal a new menu or a redesigned home page ahead of time.

The first affects all versions from 4.7 to 7.1.3, and Wordfence gives it a severity score of 8.1 out of 10 (LeBigData). This is the fourth security release of the 7.1 branch in six weeks (Astuces du Web). Do not confuse it with the alert about version 7.1.3: this is a different vulnerability, and it is already being attacked.

A vulnerability that opens during the update

During a full update, WordPress unpacks the new version into a temporary folder stored under wp-content/upgrade (LeBigData). This folder also contains the WordPress installer (LeBigData). Until now, its name contained only six random characters, few enough to be guessed, and it remained accessible from the web like the rest of the site (Astuces du Web).

An attacker who reaches this installer at the right moment can run commands on the server without a WordPress account (LeBigData). The window sometimes lasts only a few seconds. Attackers make up for this by sending requests continuously, so as to hit exactly the right moment (LeBigData).

Version 7.1.4 lengthens the folder name to 16 characters, adds an empty file that prevents its contents from being listed, and no longer copies the site's configuration file from the temporary folder (Astuces du Web).

Attacks already under way

Wordfence, a WordPress security specialist, says it blocked 62,969 attempts targeting this vulnerability in 24 hours (The Hacker News). Its protection intercepted a first suspicious request just nine minutes after going live, and that protection had itself been deployed about three hours after the fix was released (LeBigData).

This figure counts blocked attempts, not hacked sites (LeBigData). The signal is still clear. On 3 November 2026, the US cybersecurity agency CISA added this vulnerability to its catalogue of actively exploited vulnerabilities (CISA).

Is your SME in Abidjan, Dakar or Lyon? It makes no difference. These bots test every WordPress site they find, regardless of the size of the business.

The trap: the fixing update runs through the old code

This is the most frequently overlooked point. When you install 7.1.4, it is still the old update program, the one containing the vulnerability, that unpacks the files (The Hacker News). An attacker who strikes at that precise moment can therefore still execute code (The Hacker News).

Hence the recommendation from the researcher quoted by The Hacker News: block public access to the wp-content/upgrade folder before starting the update (The Hacker News). WordPress works on this folder directly on the server's disk. Closing it to visitors therefore does not block updates (The Hacker News).

Checking your site's version

Log in to the admin area and open Dashboard > Updates: the installed version number is shown there (Astuces du Web). If automatic security updates are enabled, the upgrade to 7.1.4 may have happened on its own overnight (Astuces du Web). In that case, go straight to the warning signs below.

Older branches have received their own patches: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 4.8.34 and 4.7.39 (Astuces du Web). However, only the most recent branch is actively maintained (LeBigData). If your plugins allow it, aim for 7.1.4.

Updating WordPress safely, in the right order

Make a full backup of both the files and the database before any update, even a minor one (Astuces du Web). Keep a copy off the server.
Block public access to the wp-content/upgrade folder. On an Nginx or Apache server, this is done in the server configuration. If you can only edit the .htaccess file, a single line is enough, placed at the root of the site, above the WordPress rules: "RedirectMatch 403 ^/wp-content/upgrade/" (The Hacker News). Pass this instruction on to your hosting provider or service provider. One precaution: do not put the .htaccess file in the folder itself, because the old update program empties that folder before using it (The Hacker News).
Check that the block works. Type your site's address followed by /wp-content/upgrade/ into a browser. You should get a 403 error, meaning "access denied" (The Hacker News). If a list of files appears, the server is displaying the contents of its folders: fix this before going any further (Astuces du Web).
Choose a quiet time slot. Few customers online, and someone available to monitor the site afterwards. This time slot protects your sales if something breaks, not your site: bots never sleep. Blocking the folder is what protects you.
Run the update, then check your key pages and your contact form (Astuces du Web). For an online store, place a test order all the way through to payment.
Clean up. Delete the accounts of former writers, interns or contractors, since most of the other vulnerabilities start from a Contributor or Author account (Astuces du Web). If a confidential change was waiting in the Customizer, assume it may have been seen, and either publish it or delete it (Astuces du Web).

The folder block can stay in place after the update. It does not interfere with the normal operation of WordPress (The Hacker News).

Warning signs to look out for

If your site updated itself, or if you updated without blocking the folder, have the following checked. Wordfence recommends looking for (LeBigData) (The Hacker News):

in the server logs (the record of visits kept by your hosting provider), requests to PHP files located under wp-content/upgrade;
administrator accounts that nobody recognizes;
plugins installed without your knowledge;
unknown PHP files on the server.

Any one of these signs is reason enough to act. Do not delete anything in a hurry: these traces help to understand what happened. Ask your hosting provider to keep the logs, change the administrator passwords, then have the site examined.

If your site is very old

Versions 4.6 and earlier no longer receive any patches (Astuces du Web). The only option is to migrate to a maintained version, after a full backup and a trial run on a copy of the site, because it is a big jump (Astuces du Web). Take the opportunity to check your site's PHP version, the language that runs WordPress on the server.

What you can do this week

Open your dashboard and note your version. If it is not up to date, send your service provider the instruction for blocking the folder, then schedule the update, including the backup. If nobody looks after your site, DiGit Summit's Web security & maintenance team can handle these updates, backups and monitoring, starting with a free initial audit.

Frequently asked questions

My site updated itself to 7.1.4: am I protected?

Against the vulnerability itself, yes, once 7.1.4 is installed. But the automatic update was carried out by the old code, which remained vulnerable for a few seconds. Have the server logs, administrator accounts, plugins and any PHP files under wp-content/upgrade checked.

Does blocking the wp-content/upgrade folder prevent future updates?

No. WordPress uses this folder directly on the server's disk, without going through the web. Closing it to visitors does not interfere with updates, and the block can stay in place afterwards.

My hosting provider manages WordPress for me: do I still need to act?

At the very least, check the version number under Dashboard > Updates, as only this number is reliable. Also ask your hosting provider whether public access to the wp-content/upgrade folder is blocked. Cleaning up old accounts and Customizer drafts remains your responsibility.

Could the 7.1.4 update break my site?

It is a security release, intended to fix vulnerabilities. A backup beforehand is still essential, especially with a theme or plugin that is poorly maintained. After the update, test your key pages, your contact form and, for an online store, an order all the way through to payment.

What should I do if my site runs WordPress 4.6 or older?

These versions no longer receive any security patches. You need to migrate to a maintained version, preferably 7.1.4. First make a full backup and do a trial run on a copy of the site, because it is a big version jump.

Sources

Was this article helpful?

WordPress 7.1.4: the vulnerability that strikes during the update