CVE-2026-119977 is a flaw in the way WordPress updates itself. For a few seconds during a big core update, a stranger can run code on your server. It’s fixed in WordPress 7.1.4, attackers are trying it every day, and most sites are already safe. Here’s how to make sure yours is.
Last updated: 7 November 2026.
In 30 seconds
- Update WordPress to 7.1.4 (or the fixed version of your branch). Most sites did it on their own on 28 October.
- Don’t turn off automatic updates. The flaw is in the update process, but the fix is still the update.
- Still on an old version, about to make a big jump? Block
wp-content/upgrade/first. Here’s the line to add. - Take five minutes to check for signs of a hack. Here’s how.
What is CVE-2026-119977?
When WordPress installs a full update of itself, it first unpacks the complete new version into a folder called wp-content/upgrade/, then copies the files into place. That copy includes the WordPress installer, the page you see when you set up a brand new site. Until 7.1.4, that folder had a predictable name, and on many servers anyone could open it in a browser.
So for the few seconds the update takes, an attacker who keeps knocking on that folder can reach the installer, point it at their own database, and end up running their own code on your server. No password needed. That’s the whole trick: a race against your own update.
WordPress fixed it on 28 October in 7.1.4 (a release with 22 security fixes in total), and in every older branch down to 4.7. The staging folder now gets a random name, and the installer can’t be used from there anymore. On 3 November, CISA (the US cybersecurity agency) added it to its list of flaws that are actively exploited, and a working attack was published on GitHub the next day.
Is my site affected?
In wp-admin, open Dashboard → Updates and look at your version. You’re fixed if you’re on one of these, or newer:
| Your WordPress branch | Fixed from |
|---|---|
| 7.1 | 7.1.4 |
| 7.0 | 7.0.8 |
| 6.9 | 6.9.11 |
| 6.8 | 6.8.12 |
| 6.7 | 6.7.11 |
| 6.6 | 6.6.11 |
| Older, down to 4.7 | The last release of that branch (4.7.39 for 4.7) |
Now the honest part. Being on an old version doesn’t mean you were hacked, and the risk is much smaller than the headlines suggest. For an attack to work, several things have to line up at the same moment:
- Your site is in the middle of a full core update. Plugin and theme updates don’t count.
- The update uses the full package. Small security updates like 7.1.3 → 7.1.4 usually use a partial package, without the installer. Full packages are for big jumps (6.9 → 7.1), a “Re-install” from the Updates screen, or sites whose core files were edited.
- Your server lets visitors open files in
wp-content/upgrade/. Many hosts don’t. - The attacker wins the race, within a window of a few seconds.
That’s why WordPress itself rates the flaw “Low”, while Wordfence gives it 8.1 out of 10. I think both are right. The window is tiny, but bots don’t get bored: Wordfence has blocked over 240,000 attempts so far, with a peak of 74,000 on 30 October alone. So far, nobody has publicly reported a site actually hacked this way.
What do I need to do?
1. Update. Open Dashboard → Updates. If WordPress offers a new version, take it. If it says you have the latest version, you’re done with the important part. On managed hosting (Kinsta, WP Engine, WordPress.com and the like), the host usually updates core for you; it only takes a glance at that screen to confirm.
2. Keep automatic updates on. I’ve seen people suggest turning them off “since updates are the problem”. Please don’t. This flaw is fixed, the next one will be fixed the same way, and a site that stops updating ends up with dozens of known holes instead of a few seconds of risk. WordPress also announced on 29 October that security releases will now come more often, so automatic minor updates matter more than ever.
3. Block the staging folder, especially before a big jump. If your site isn’t on a fixed version yet, the update itself runs the old, vulnerable process one last time, and a big jump (6.x to 7.1, for example) uses the full package. Close the door first, as Wordfence also recommends. Nobody ever needs to open wp-content/upgrade/ in a browser, and WordPress keeps writing to it normally, so this changes nothing for your updates. On Apache (most shared hosting), add this line at the top of the .htaccess file at the root of your site:
RedirectMatch 403 ^/wp-content/upgrade/On Nginx, add this to your site’s server block, then reload Nginx:
location ^~ /wp-content/upgrade/ { deny all; }To test it, open https://yoursite.com/wp-content/upgrade/ in your browser. You should get a “403 Forbidden”. Not comfortable editing server files? Ask your host:
Hi, about the WordPress update flaw CVE-2026-119977: could you confirm my site is on WordPress 7.1.4 (or the fixed version of its branch), and that web access to the wp-content/upgrade/ folder is blocked on my server? Thank you!
How would I know if I was hacked?
If your site was already fixed on 28 October, the chance is close to zero. If it made a big core update recently on an older version, take five minutes:
- Users: in wp-admin, open Users and filter by Administrator. Anyone you don’t know?
- Plugins: anything installed that you didn’t install?
- Strange files: a
.phpfile insidewp-content/uploads, or anything left insidewp-content/upgrade/long after an update. - Your server logs, if you can read them: requests to
wp-content/upgrade/that ask forsetup-config.phporinstall.php. Those are the attack. Most will be blocked attempts, but any answered with a 200 deserve a closer look. - Google: search
site:yourdomain.comand look for pages you never wrote.
If anything looks wrong, ask your host to scan the server and restore a backup from before it appeared, then change your passwords (WordPress, hosting, database). I wrote more about what to look for in the PHP2Shell guide.
Quick answers
Are plugin and theme updates affected? No. Only full updates of WordPress itself unpack the installer. Updating your plugins and themes is as safe as it was last week.
I use the free version of Wordfence. Am I protected? Its firewall rule for this flaw reaches free users on 27 November, after the usual 30-day delay. The update protects you today; don’t wait for the rule. And on any plan, the rule only catches this attack when the Wordfence firewall is optimized in Extended Protection mode, since the attack calls files that never load WordPress.
Do I need a security plugin for this? No. The update is the fix, and blocking the folder is a one-line extra. A plugin can’t help much here anyway: the attack targets files that are only there during the update.
Is it the same as PHP2Shell? No. PHP2Shell was a flaw in PHP, on the server, which a WordPress update can’t fix. This one is in WordPress, and a WordPress update fixes it.
I look after many client sites. Where do I start? Check the version of every site (wp core version with WP-CLI is the fastest). Start with the ones still on old branches, since they’re the ones that will make a full update next, and block the folder on those first.
Timeline
- Before 28 October Umut Bayram (Picus Security) reports the flaw privately to the WordPress security team.
- 28 October WordPress releases 7.1.4, with the fix backported to every branch down to 4.7. Wordfence deploys a firewall rule for its paid users, and logs the first attack attempt nine minutes later.
- 29 October WordPress announces that security releases will now come more often.
- 30 October Attacks peak: Wordfence blocks over 74,000 attempts in a single day.
- 3 November CISA adds CVE-2026-119977 to its catalog of actively exploited flaws.
- 4 November A working proof of concept is published on GitHub.
- 27 November The Wordfence rule reaches free users.
Sources: the WordPress 7.1.4 announcement, BleepingComputer on the CISA listing, Wordfence’s attack report, and WordPress’s Core Security Initiative update.
Hear about the next one early
There will be a next one. If you work with an AI assistant (Claude, ChatGPT, Codex, Cursor…), connect it to Today WP ↗, a free server we made that knows what is true in WordPress today. Give it your WordPress and PHP versions and your plugins, and it tells you what to update first: core security releases, PHP branches that no longer get fixes, and known vulnerabilities in the exact versions you run, refreshed every day. It’s read-only and needs no account. Add https://todaywp.com/mcp as a connector, then ask it: is my site safe?
Read next: this flaw needs your update to work. The bigger risk is the services that hold keys to thousands of sites at once. The next big WordPress hack.
Questions? Come talk about it on our Discord. Stay safe 🙂
