Safe WordPress Core Update: Block wp-content/upgrade Before You Patch

WordPress 7.1.4 fixes CVE-2026-119977, an actively exploited core flaw, but the update that installs the fix can still leave a temporary installer reachable under wp-content/upgrade for a few seconds. A safe WordPress core update this week means blocking that folder on the web first, then updating, then checking what changed.

Should you still update WordPress this week?

Yes. Update now, but block web access to wp-content/upgrade before you do. CVE-2026-119977 affects every WordPress core release from 4.7 through 7.1.3. WordPress fixed it last week in 7.1.4 and in matching releases for each older branch back to 4.7, all listed in its security advisory.

Staying on an affected version is the worse choice by a wide margin. What changes is the order: lock the folder, update, then check for leftovers.

CISA added the flaw to its Known Exploited Vulnerabilities catalog earlier this week, citing evidence of active exploitation. The agency did not describe the attacks. KEV deadlines bind only U.S. federal civilian agencies under Binding Operational Directive 22-01. For a small business site, the listing is a prioritization signal: someone is already using this.

The severity ratings disagree. Wordfence, which assigned the CVE, scores it 8.1 on CVSS, inside the High band. WordPress’s own advisory rates it low. In Wordfence’s lab tests the exploitable window lasted only seconds.

But attackers are patient. Wordfence saw the first attempts nine minutes after it deployed a firewall rule on release day. Two of the busiest sources then kept checking small groups of sites for about 14.5 hours, which Wordfence interprets as an effort to catch sites mid-update. That is more than 50,000 seconds of polling aimed at a window measured in seconds.

Why the patch can't protect its own installation

The code that unpacks an update is the code already installed on your site, not the code inside the new package. So the fix arrives through the very updater it is meant to repair.

Here is the flaw itself. When WordPress applies a complete update package, it extracts a temporary copy of the new version into a folder inside wp-content/upgrade. That copy includes the WordPress installer files, and on most servers the folder is reachable over the web.

An attacker with no account on your site who can work out the folder’s name and load the installer before WordPress deletes the copy can set that copy up as a brand-new WordPress site.

A fresh installer asks for database details and creates its own administrator account. The attacker points it at a database they control, so they never need your real database password. They log in to the temporary copy and run PHP with the web server’s permissions, which lets them read and write your live site’s files before the copy disappears.

The fix has two parts:

• It gives the temporary folder a random name.
• It stops a wp-config.php placed in the temporary copy from being copied over your real configuration file.

The second part already protects you during the update that installs it, because the step that copies files into place runs the new code. Before the fix, an attacker could plant a wp-config.php in the temporary copy and let the update overwrite your real one. That route is closed. The first part does not help yet: the old updater still creates and names the folder.

Umut Bayram, the Picus Security researcher who found the flaw, put it plainly to The Hacker News on November 6: the deciding factor “isn’t partial versus complete. It’s whether the updater already installed on the site has been fixed.”

That is why your current version matters. On sites running 5.9 or later, the old updater names the temporary folder after the downloaded file, so the name is predictable one final time. On 4.4 through 5.8, it adds random characters, which hides the name unless the site leaks it some other way, such as in an error message.

Code running as the web-server account is not automatically root. How far it reaches depends on file permissions and hosting isolation. On poorly isolated shared hosting, one account may be able to read other sites or their configuration files. We covered a different route from WordPress core to server control in our write-up of Comment2Shell (CVE-2026-93485), and the same blast-radius thinking applies here.

Which of your updates actually open that folder?

Any update that unpacks installer files into wp-content/upgrade opens the window, and complete packages always do. A partial package, built for one specific starting version, exposes a site only if that package happens to contain the installer files.

Which one you get depends on where you start. The Hacker News queried WordPress.org’s update service on November 6:

• An in-branch move such as 7.1.3 to 7.1.4 was offered a partial package, including for automatic updates.
• A cross-branch move such as 7.0.7 to 7.1.4 was offered only complete packages.

Even when a partial package exists, WordPress falls back to a complete one if your core files do not match the official checksums, or if you are reinstalling. A modified core file, an old hack that was never fully cleaned up, or a click on “Re-install version” all push you onto the complete package.

Automatic background updates use the same updater and the same steps, so they hit the same brief window. WP-CLI is no shortcut either: wp core update runs the same updater and unpacks into the same folder.

Should you switch automatic updates off? We would not. Disabling them leaves you on a version CISA says is under active attack. Block the folder at the web server and let the update land. Following Bayram’s point, treat every update to the fix as exposed unless you know your installed updater is already patched, rather than betting on a partial package.

How do you block wp-content/upgrade for a safe WordPress core update?

Tell the web server to refuse every HTTP request for wp-content/upgrade, either in the server configuration or in the site’s root .htaccess. WordPress works with that folder directly on disk, so denying web access does not break updates. It only stops anyone from loading a staged installer through a browser.

1. Nginx: add location ^~ /wp-content/upgrade/ { deny all; } to the site’s server block.
2. Apache with vhost access: add Require all denied inside a <Directory> block for that folder in the virtual host configuration.
3. .htaccess only: add RedirectMatch 403 ^/wp-content/upgrade/ to the .htaccess in the WordPress root, above the WordPress rewrite rules.
4. Test from outside, on the public side of the site: request a path under /wp-content/upgrade/ and expect HTTP 403.
5. Update to 7.1.4 or the fixed release for your branch.

A 404 just means nothing is at that path right now; it proves nothing about whether a staged installer would be refused. Only a 403 confirms the rule works.

Where you put the rule decides whether it works:

• Not inside the folder. An .htaccess placed in wp-content/upgrade is useless, because the old updater deletes everything in that folder before it unpacks an update.
• Nginx ignores .htaccess entirely. If Nginx serves your site, or sits in front of Apache and answers requests itself, the deny must live in the Nginx configuration.
• Apache root .htaccess depends on overrides. If the server config does not allow the relevant override, your rule is silently skipped. A vhost rule does not have that problem.

Practitioner’s note: on client sites we regularly find hardening rules pasted into an .htaccess the server never reads, usually because a managed host runs Nginx in front. The file looks correct and protects nothing. The outside 403 test takes ten seconds and catches this. If you cannot edit server config, ask your host to add the rule before you update.

To avoid the window entirely, update manually outside the web root, where no temporary installer is ever created in a served folder:

1. Back up your files and database.
2. Unpack the new release in a directory the web server does not serve.
3. Copy the core files over your site without touching wp-config.php or wp-content.
4. Run the database update when WordPress prompts for it.

What should you check in the minutes after the update?

Check for the four signs Wordfence suggests hunting for, especially if your site sat on an affected version while attackers were probing:

• Unexpected requests to PHP files under wp-content/upgrade in your access logs.
• Administrator accounts nobody recognizes.
• Plugins nobody installed.
• PHP files in wp-content/upgrade that nobody placed there.

Copy your current and rotated access and error logs somewhere safe before routine rotation removes them. Do not hold the update for forensics, though. Low-rate probes spread across many sites will not show up in a list of your busiest URLs, so search for the path directly.

A log hit on the temporary installer is a lead, not proof. Look at the response code, what the same address requested next, and whether files, users, plugins or configuration changed around that time.

Running wp core verify-checksums confirms core files match the official release, but it says nothing about plugins, themes, uploads, stray PHP files, database content or admin accounts. It is not a malware scan; a full website antivirus scan covers what the checksum check skips.

If installer access lines up with unexplained changes, treat the site as compromised. Hunt for persistence first, then rotate database credentials, regenerate WordPress security salts and invalidate active sessions. Deleting one unknown admin or one odd PHP file is not a cleanup; whoever created them had file access and may have left more. If Google is already warning visitors, here is how to clear a hacked-site warning in Google.

What is still unknown, and what about very old sites?

We do not know who is exploiting CVE-2026-119977, how many sites have been hit, or what attackers did after getting in. CISA has not described the attacks, and Wordfence’s data shows attempts, not confirmed compromises.

The urgency is growing: code its authors describe as an exploit for this flaw has appeared in public GitHub repositories since earlier this week. One repository claims it also works on sites that still use a predictable folder during complete-package updates. Nobody has established that the code works, but its existence lowers the bar for the next wave of attempts.

Keep two ranges apart. The official affected range, and the range with fixes, is 4.7 through 7.1.3. Separately, Bayram says the underlying updater weakness goes back to WordPress 2.7, released in 2008. WordPress 4.6 and earlier no longer receive security updates, so those sites carry the weakness with no patch coming.

Those sites need to move to a supported version, using the blocked-folder or manual method above for the migration itself.

FAQ

Is it safe to update WordPress right now?

Yes, and it is safer than staying on 7.1.3 or earlier. Block web access to wp-content/upgrade first so the brief window during the update cannot be used.

Does WordPress 7.1.4 fix CVE-2026-119977?

Yes. It randomizes the temporary folder name and stops a temporary wp-config.php from replacing the real one. Matching fixes exist for branches back to 4.7.

Should I turn off WordPress automatic updates?

No. Automatic updates use the same path, but turning them off leaves you on an exploited version. Block the upgrade folder at the web server and let the update install.

Does WP-CLI core update avoid this WordPress bug?

No. wp core update runs the same updater and unpacks into the same wp-content/upgrade folder. Only a manual update unpacked outside the web root avoids it.

Why would PHP files appear in wp-content/upgrade?

WordPress uses the folder briefly during updates and should clean it up. PHP files nobody placed there after an update are an indicator of compromise and need investigation.

If you would rather not edit server rules yourself, or you found something in wp-content/upgrade you can’t explain, our website firewall and cleanup package blocks the upgrade path at the edge and checks the site for anything left behind.