The WordPress Core Flaw That Hits You Mid-Update: Exploitation Confirmed, and What to Do Before You Update

WordPress 7.1.4 was released on October 28, 2026. WordPress’s own post calls it a security release fixing multiple issues, and Wordfence writes that WordPress counts 22 vulnerabilities in it (WordPress, Wordfence).

The most serious is a flaw in the core update process (CVE-2026-119977). Someone with no account on the site can run code on the server during an update. On November 3, the US CISA added it to its Known Exploited Vulnerabilities (KEV) catalog (CISA data).

But this is not “anyone can get into any WordPress site.” The attacker can strike only during the very short time a core update is running. This article sets out the conditions, how to check, and what to do before you update, from primary sources. The information is current as of November 7, 2026.

Much of what circulates in Japanese differs from the original text. We read the primary sources ourselves, but we recommend that you check the originals too.

Key points

• The affected versions are WordPress core 4.7 through 7.1.3. The fixed versions are 7.1.4 for the 7.1 branch, 7.0.8 for 7.0, 6.9.11 for 6.9, and so on down to 4.7.39 for the 4.7 branch (official GitHub advisory).
• The attack works only while a core update runs from a full package. In Wordfence’s testing, that window lasted seconds (Wordfence).
• Attempts began on the day of disclosure. Wordfence says it blocked more than 240,000 of them. That is not a count of hijacked sites (Wordfence).
• Sites with automatic updates on should already be updated. Check in the admin screen.
• If not, block outside access to wp-content/upgrade/ before you update. The update itself runs, one last time, on the old update code.

The headline, and the primary sources

What happens

When WordPress core is updated from a full package, the new files are first unpacked under wp-content/upgrade/. The unpack location had a predictable name and was reachable from the web (GitHub advisory).

The discoverer, Umut Bayram, explains the mechanism on his employer’s (Picus Security) blog (Picus):

1. The unpacked files include WordPress’s setup screen (setup-config.php)
2. The setup screen in the unpack location cannot find the real configuration file (wp-config.php) one level up, and concludes that WordPress is not yet set up
3. The setup screen works without authentication, so an attacker can supply their own database and create a new configuration file
4. When the update copies the unpacked files over the live site, that configuration file can overwrite the real wp-config.php
5. A site connected to an empty database shows the setup screen, so the attacker can create the first administrator. From there, a malicious plugin can run code

Wordfence’s description is shorter: the attacker completes the staged installation, creates an administrator, and uploads PHP (Wordfence).

The attacker does not know when an update starts. So they send requests like this one, over and over, and wait for the moment.

GET /wp-content/upgrade/wordpress-6.9.11/setup-config.php

Wordfence writes that two of the largest sources repeatedly polled small groups of sites for about 14.5 hours (Wordfence).

What 7.1.4 changed

According to Picus, 7.1.4 changed three things (Picus):

• The unpack folder name gets a 16-character random suffix
• index.php in wp-content/upgrade/ is no longer deleted (this prevents the folder listing from showing)
• wp-config.php is excluded from the copy to the live site

But the update that installs this fix still runs on the old update code, because the code already on the site does the unpacking. Wordfence also writes that updating runs the vulnerable process one last time. That is why step 2 of “What to do now” matters.

Who is at risk

The conditions stack. Wordfence says all four of these are needed (Wordfence).

The ratings CISA attached to the CVE record agree: “Automatable: no,” “Exploitation: active,” “Technical impact: total” (CVE record).

The sites actually at risk look like this:

• Automatic updates are off, and updates are done by hand
• Several sites are updated by hand, one after another
• Running WordPress 4.6 or earlier (no fix was issued. Moving to a supported version is required. Picus)

What to do now

1. Check that you are updated

In the admin screen, open Dashboard, then Updates, and confirm the site is on 7.1.4 or the fixed release for your branch. Wordfence says sites with automatic updates should already be updated, but asks you to check rather than assume. Where you can run commands, this works:

wp core version

2. If not, close the path, then update

Before you update, block outside access to wp-content/upgrade/. WordPress uses this folder only inside the server. Blocking it does not stop the update (Picus).

On Nginx:

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

If you can only edit .htaccess, add this line to the .htaccess in the WordPress root, above the rewrite rules:

RedirectMatch 403 ^/wp-content/upgrade/

Putting an .htaccess file inside wp-content/upgrade/ does not work. The old update code deletes everything in that folder before it unpacks.

After setting it up, confirm that a request to /wp-content/upgrade/ returns 403, and then update. Note that the command wp core update uses the same updater, so it is not a substitute (Picus).

Wordfence also lists blocking PHP access on the web server before updating as an additional precaution. Its firewall protects you only on the paid versions with “Extended Protection” on. The free version gets the same protection on November 27.

3. Even if updated, read the logs

A site fixed by an automatic update should still be checked once for whether it was targeted while the update ran. In the access log, look for outside requests to PHP files under /wp-content/upgrade/. No legitimate update calls these files from outside (Wordfence).

grep -E "/wp-content/upgrade/.*\.php" access.log

The log location differs by environment. The sources Wordfence calls especially suspicious are these:

103.59.160.171
2001:df1:e8c0::106b
51.89.103.78
185.177.72.61
195.3.220.7
96.62.218.148
20.217.186.29
87.58.197.83
154.26.238.8
20.46.43.126

Also check wp-content/upgrade/ for leftover files, and look for administrators or plugins you do not recognize. A clean log does not prove the site was not compromised (Wordfence).

How it was found

The discoverer, Bayram, writes on his employer’s blog that he used an AI model (in his words, “GPT 5.6 Sol”) as his research partner, and that it took about four hours from his first look to a working exploit chain. He also writes that the flaw had been in the update process since WordPress 2.7, released in 2008 (Picus). Both are the company’s own account and are not confirmed by other sources.

What we could not confirm

• Whether any site has actually been taken over through this CVE. Wordfence writes that the 240,000 attempts are not a count of compromises, and that most are probably automated attempts
• The 240,000 is the number Wordfence blocked with its own product. It is not a count for the whole internet
• How Japanese hosting companies are responding. We could not find a JPCERT/CC or IPA notice
• “Since 2008” and “about four hours” come from the discoverer’s employer
• The fixed versions go back to 4.7, while Picus writes that the updater behavior goes back to 2.7. We could not confirm whether the attack actually works on 4.6 and earlier

Related articles

• Haven’t Updated PHP Yet? Where PHP2Shell Stands and What to Check Now: checking updates on the server side
• CVE Registrations in 2026 Are More Than Double Last Year: Recounting the Data Behind the Viral Chart, and Where the Increase Is (and Is Not): taking an inventory of what you use
• The OpenSSH Flaw “*sshole”: Only Linux Systems Like Alpine Are Affected. How to Check and What to Do: a server-side flaw from the same week

If you need help checking your WordPress site’s updates or reviewing its access logs, please contact us.