CVE-2026-119977 in WordPress: a flaw in the update process that lets attackers run code on the server

On 28 October 2026 WordPress released version 7.1.4, which fixes a flaw in the way WordPress updates itself: during a core update that uses the full package, WordPress unpacks the new files into a folder with a predictable name that any visitor can reach from the web, so an attacker with no account on the site can run code on the server. Within hours of the fix, attackers began trying to exploit it, and on 3 November the CISA agency added the flaw, CVE-2026-119977, to its catalogue of exploited vulnerabilities, meaning it has evidence of the flaw being exploited in real attacks. The flaw affects every WordPress version from 4.7 to 7.1.3, unless the site already runs the patched version for its branch. This article covers how the flaw works, how to tell whether your site is affected, how to protect it before you update, how to update it, and how to look for signs of a break-in.

01What happened

Researcher Umut Bayram of Picus Security reported the flaw to the WordPress team, which fixed it in 7.1.4 along with 21 other vulnerabilities, most of them XSS, and published patched versions for every older branch down to 4.7. Wordfence released a firewall rule that blocks the attack about three hours after the announcement; the first request matching it arrived nine minutes later, and in the first 21 hours Wordfence recorded more than 18,500 requests looking for the installer in the temporary update folder.

WordPress rated the flaw low severity, because exploiting it needs precise timing. Wordfence, which gave it its number on 31 October, scored it 8.1 out of 10, that is, high severity: exploitation is hard, but whoever succeeds can run anything on the server. CISA then added it to its catalogue on 3 November and gave US government agencies until 6 November to close it.

02How the flaw works

When WordPress updates its core, it downloads the package of the new version and unpacks it into a temporary folder inside wp-content/upgrade, then moves the files into place and deletes the folder. The whole process takes seconds. Before 7.1.4, the temporary folder was named after the package, so an attacker knew its name in advance, and on many servers the folder was served on the web like any other folder of the site. Worse, the cleanup step before the update deleted the index.php file that hides the folder’s contents from visitors.

The full package is a complete copy of WordPress, including the installer: the page that writes the configuration file when a new site is set up, and which runs without the site’s configuration because it was built for a site that is not installed yet. If the attacker requested it the moment the folder appeared, they pointed it at a database they control, and it wrote a new wp-config.php file pointing there into the temporary copy. The update itself then copied that file over the site’s real one, so the site started reading from the attacker’s database, which held an administrator account the attacker had set up, and the attacker logged in with it and ran any code they wanted through the theme editor or by uploading a plugin.

That is why this flaw is called a race condition: the temporary folder exists on the server for only a few seconds during the update, and the attacker succeeds only by reaching it within those seconds. Since they do not know when your site will start an update, they request the same path over and over for hours, until they catch the moment the folder appears.

The fix closes the path from three sides: it adds 16 random characters to the temporary folder’s name so it cannot be predicted, it keeps the index.php file in the upgrade folder, and it stops the update from copying the wp-config.php file out of the temporary copy.

03Is your site affected

Every site running WordPress 4.7 to 7.1.3 is affected, unless it runs the patched version for its branch. The attack succeeds if four conditions meet:

1. 01A core update using the full package: Only the full package carries the installer files; plugin and theme updates do not.
2. 02A wp-content/upgrade folder served on the web: PHP files run in it, which is the default on most servers.
3. 03A predictable folder name: As in every version before 7.1.4.
4. 04Enough time: The attacker’s request has to arrive before WordPress deletes the temporary files.

A site owner does not usually choose which package an update uses, so treat every core update on an affected version as an open window, including the very update that brings the fix: an affected site unpacks the patched version’s package with the old update code, one last time.

Know your version

You will find your version number in the WordPress dashboard, on the Updates page, or with the wp core version command if you have WP-CLI. Then compare it with the patched version for your branch:

Only version 7.1.4 is supported today; WordPress releases the older branches’ versions as a courtesy. No security fixes reach 4.6 and earlier, and Patchstack says the weak spot in the update code dates back to WordPress 2.8, so do not assume those versions are safe.

04Close the upgrade folder before you update

No one needs to reach the wp-content/upgrade folder from the web: WordPress reads and writes it directly on the disk, and blocking it does not break any update. So block it before you update, and the window stays shut even during the last update run by the old code. Put the rule in the site’s configuration, not inside the upgrade folder itself, because the cleanup step in affected versions deletes whatever is in it.

On Apache or LiteSpeed

Add these lines at the top of the .htaccess file in the site’s main folder, before the # BEGIN WordPress line, because WordPress rewrites whatever sits between its markers:

# Blocks every web request to the upgrade folder and answers it with 403<IfModule mod_rewrite.c>RewriteEngine OnRewriteRule ^wp-content/upgrade/ - [F,L]</IfModule>

On nginx

Add this block inside your site’s server block, then test the configuration and reload it:

location ^~ /wp-content/upgrade/ {    deny all;}# Then: nginx -t && systemctl reload nginx

Then make sure the block works: both of the following commands should print 403.

curl -sI https://maktabat-alweibdeh.com/wp-content/upgrade/ | head -1curl -sI https://maktabat-alweibdeh.com/wp-content/upgrade/index.php | head -1

05Update WordPress and check the version

1. 01Take a backup: Covering the site’s files and its database together, and keep it somewhere safe.
2. 02Block the upgrade folder: As in the previous section, before you start the update.
3. 03Update: In the dashboard open Updates and click Update Now, or download 7.1.4 from wordpress.org and upload its files yourself.
4. 04Check the version: Open Updates again and make sure the number is now 7.1.4 or the patched version for your branch.

If you have WP-CLI, you can do the same from the terminal, in the site’s folder:

# The current version, then update to the latest version, then checkwp core versionwp core updatewp core version# Compare the core files with the official releasewp core verify-checksums

The best move is to 7.1.4, the only supported version. If moving to a newer branch needs time to test your theme and plugins, the wp core update --minor command updates your site to the patched version for its branch, which closes this flaw.

Sites with automatic updates on update themselves, but check the version number yourself rather than assume. Sites where automatic updates are off, through the AUTOMATIC_UPDATER_DISABLED setting or WP_AUTO_UPDATE_CORE false, or that a developer manages through Composer or a deployment tool, will not update on their own.

ProblemThe message Another update is currently in progress appears

FixAn earlier update that did not finish left a lock, which clears by itself after 15 minutes. Wait, then try again.

ProblemThere is no update button on the Updates page

FixUpdates are turned off in wp-config.php, or someone else manages the site. Ask whoever manages it, or update by hand from wordpress.org.

ProblemMy site runs 4.6 or earlier

FixThere is no fix for your branch. Take a backup, try the move to a supported version on a test copy of the site first, and keep the upgrade folder blocked until you are done.

ProblemI updated: am I done?

FixUpdating shuts the door but does not remove anyone who got in before. Check your site as in the next section.

06Was your site exploited?

The window opened with every core update on an affected version, including the update that brought the fix, and attackers started knocking within hours of its release. So even a site that updated itself automatically deserves a quick check, and what matters most is what happened in the minutes around the time of the update:

# 1. Requests to PHP files inside the upgrade folder; the path is an example for nginx logszgrep -h 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log*# 2. The database the site connects to, and when the config and version files last changedgrep -E "DB_(HOST|NAME|USER)" wp-config.phpls -l --time-style=full-iso wp-config.php wp-includes/version.php# 3. Administrator accounts, and the integrity of the core fileswp user list --role=administratorwp core verify-checksums

• A successful request to a PHP file inside wp-content/upgrade: Ordinary visitors never request these files. The most serious is a POST request to setup-config.php that the server answered with 200.
• A wp-config.php file pointing to a database you do not know: Or one whose modification time matches the time of the update, because core updates never write this file.
• An administrator you did not create: Or a plugin or theme you do not recognise, new PHP files in the uploads or mu-plugins folder, or core files that do not match the official release.

07If you are an Illevante customer

• cPanel hosting: The web server on our hosting is LiteSpeed, which reads the .htaccess file, so the blocking rule in this article works on it as it is. Add it from File Manager in cPanel, after turning on hidden files in its settings.
• Access logs: You will find them in cPanel, in the Metrics section under Raw Access. Download them and search them for requests to wp-content/upgrade.
• JetBackup copies: A copy of your site is taken automatically every day and kept for 15, 30 or 45 days depending on your plan. Take a manual copy before you update, and if you find signs of a break-in, restore a copy from before the update in JetBackup.
• A CoreVPS server: If WordPress runs on your server, whether you picked it as an app when ordering or installed it yourself, the web server and its configuration are in your hands: add the matching nginx or Apache rule, and update WordPress yourself.
• If you need a hand: Our technical support team is with you around the clock if you need help blocking the folder or checking your site.

08The lesson: the update itself needs protecting

This flaw lives for only a few seconds during an update, yet it drew tens of thousands of requests. Three habits protect your site from its kind:

1. 01Temporary folders are not for the web: Keep wp-content/upgrade blocked all the time, not only during updates, because nothing in it is meant for a visitor.
2. 02Automatic updates, then a check: Keep automatic updates on for security releases, and check the version number after every security release.
3. 03Logs that let you look back: Keep access logs for weeks rather than days: a flaw is often announced after its door has already been open, and only the logs can tell you who came through.