CVE-2026-119977: WordPress Core Flaw Under Attack During Updates (What to Do)

Last updated November 4, 2026: CISA, the US government’s cybersecurity agency, added CVE-2026-119977 to its list of known exploited vulnerabilities on November 3 and gave federal agencies until November 6 to fix it. WordPress fixed the flaw in WordPress 7.1.4 on October 28, and attackers started probing for it within hours. Below: what the flaw is, which versions are affected, how to check your site, and what to look for if you think you were hit.

A WordPress core flaw is being used in real attacks. It’s tracked as CVE-2026-119977, it lives in WordPress itself rather than in a plugin, and it can let someone run their own code on your server without logging in. The catch for attackers is timing: it only works during the few seconds your site is installing a WordPress update. Wordfence says attackers are hammering sites with repeated requests to catch that moment. The fix is a WordPress security update, version 7.1.4, and most sites got it automatically. Most is not all, so check yours.

What is CVE-2026-119977?

CVE-2026-119977 is a high-severity WordPress core flaw that lets an attacker without an account run code on your server during a WordPress update.

Here’s how it works, according to the Wordfence write-up. When WordPress installs a full update package, it unpacks the new files into a temporary folder under wp-content/upgrade with a predictable name. That temporary copy includes the WordPress installer. On many servers the folder can be reached from the web, so an attacker who requests the staged installer at exactly the right moment can use it to run PHP code on the server.

The timing is what keeps this from being a disaster. Wordfence says the staging folder normally existed for only seconds in its lab tests, which makes a single lucky request unlikely. Attackers get around that with automation, polling the same paths over and over until an update happens. Wordfence rates the flaw 8.1 (High) on CVSS and credits Umut Bayram of Picus Security with finding it. The NVD entry describes it the same way: predictable, web-accessible staging paths used during full-package core upgrades.

Is my WordPress site affected by CVE-2026-119977?

Yes, if your site runs WordPress 4.7 through 7.1.3 and hasn’t installed the security release for its branch. WordPress 7.1.4, 7.0.8 and 6.9.11 are fixed.

WordPress fixed the flaw in WordPress 7.1.4 on October 28 and backported the fix to every older branch down to 4.7. So you don’t have to be on the newest version to be safe. You need the newest release of whatever branch you’re on. These are the fixed versions Wordfence lists for the most common branches:

WordPress 4.6 and older get no security updates at all, Wordfence notes, so a site that old needs a real upgrade, not a patch.

Is CVE-2026-119977 being exploited?

Yes. CISA listed it as actively exploited on November 3, and Wordfence saw attackers probing for it within minutes of the fix going public.

On November 3, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog, its list of flaws attackers are using, and gave US federal agencies until November 6 to fix it. The entry is also flagged for CISA’s forensic triage requirements, so agencies are expected to look for signs of compromise, not just install the update. That deadline only binds federal agencies, but it’s a good one to borrow.

Wordfence’s numbers show how fast this moved. It pushed a firewall rule for the flaw about three hours after WordPress released the fix, and the first attack request hit that rule nine minutes later. In the first 21 hours, Wordfence recorded more than 18,500 requests aimed at staged setup-config.php installer paths. Two of the busiest sources kept polling small groups of sites for about 14.5 hours, which is what you’d do if you were waiting for an update to start. When we checked its advisory on November 4, Wordfence said it had blocked 14,815 attacks on this flaw in the previous 24 hours.

The Hacker News also reports that the security firm Previdian recorded three exploitation attempts against its honeypots on October 30, from an IP address in the UK.

Did WordPress automatic updates already fix my site?

Probably, but don’t assume it. WordPress pushed 7.1.4 as an automatic background update, and Wordfence recommends checking your version to confirm it installed.

WordPress says that sites which support automatic background updates start the update on their own. Not every site does. Automatic updates can be switched off by a host, a plugin or a setting, and an update can fail without anyone noticing. Wordfence’s advice is to go to Dashboard, then Updates, and confirm you’re on 7.1.4 or the patched release for your branch, rather than trusting that it happened.

How do I check my WordPress version?

In your WordPress dashboard, go to Dashboard, then Updates. The page shows your current version and whether an update is waiting.

1. Dashboard, then Updates. The top of the page says which version you have. If it offers WordPress 7.1.4 (or the security release for your branch), you’re not patched yet.
2. Tools, then Site Health, then Info. Open the WordPress section. The first line is your version.
3. The admin footer. Most dashboards show “Version” and the number in the bottom right corner.

Compare what you see with the table above. 7.1.4, 7.0.8 or 6.9.11 means you’re fixed. 7.1.3, 7.0.7 or anything older on its branch means you’re not.

How do I install the WordPress security update?

Back up your site, then go to Dashboard, then Updates, and click Update Now. If your host or developer manages updates, ask them to install it today.

That’s the route WordPress recommends, and it’s the same one-click update you’d use for any release. Take a backup first, because a core update touches every core file. If the update fails, or you’re on an old branch and not sure what will break, that’s the moment to get help rather than keep clicking.

One more thing about the timing. The flaw only bites during an update, so the safest update is the one that happens soon, while attackers are still learning which sites are worth polling. Waiting doesn’t avoid the risky window. It just pushes it later.

How can I tell if my site was attacked through CVE-2026-119977?

Look for requests to PHP files under wp-content/upgrade in your logs, admin accounts you don’t recognize, plugins you didn’t install, and PHP files you didn’t put there.

Those are the signs Wordfence lists for sites that stayed unpatched:

• Unexpected requests to PHP files beneath wp-content/upgrade in your server’s access logs
• Administrator accounts nobody on your team created
• Plugins that appeared without anyone installing them
• PHP files in your site’s folders that you didn’t put there

Wordfence also suggests running a security scan after you update. If you find any of these, treat it as a break-in, not a glitch: change passwords, remove the unknown accounts and files, and check for anything left behind. Our guide to what a hacked WordPress cleanup really costs walks through what that involves.

Does a security plugin protect my site from CVE-2026-119977?

A firewall can block the attack while you update, but it doesn’t replace the update. Wordfence says installing the fixed WordPress version is what removes the flaw.

There’s a wrinkle with plugin firewalls here. The attack requests a staged PHP file directly, without loading WordPress first, so a firewall that only runs inside WordPress never sees it. Wordfence tells its users to enable Extended Protection, which runs the firewall before direct PHP requests reach the file. Wordfence also notes its free version gets the rule after a 30-day delay, on November 27, while paid plans got it on October 28. Either way, its own advice is: “Do not rely on the firewall instead of patching.”

What else does WordPress 7.1.4 fix?

WordPress 7.1.4 is a security release that also fixes several stored cross-site scripting bugs, a denial of service issue and a data exposure bug. Wordfence counts 22 vulnerabilities in total.

The release notes list the upgrade-window flaw first, then a run of stored XSS issues in blocks, the Customizer and the Interactivity API, a way for unauthenticated visitors to discover unpublished Customizer changesets, a Notes permissions bug, and updated root certificates. Most of the others need a logged-in Contributor, Author or Editor account to exploit, which makes them less urgent than the upgrade-window flaw. That’s another reason to install the whole release rather than chase one bug.

Is CVE-2026-119977 the same as PHP2Shell?

No. CVE-2026-119977 is in WordPress itself and is fixed by a WordPress update. PHP2Shell is in PHP, the software on your server, and is fixed by your host updating PHP.

They hit in the same two weeks, so it’s easy to mix them up, but they’re separate problems with separate fixes. PHP2Shell needed a PHP update on the server, which only your host can do. This one needs a WordPress update, which you can usually do yourself from the dashboard. It’s also not the same as WP2Shell, the WordPress flaw fixed back in July. If you haven’t kept up with the 7.x releases, our rundown of what changed in WordPress 7.0 and 7.1 covers the rest.

What is Snazzy Solutions doing about CVE-2026-119977?

We’re confirming that every WordPress site on our servers is on a patched release. If you host elsewhere, check your version today or ask us to.

Keeping core, plugins and themes updated is part of every WordPress maintenance plan we run, and our hosting includes it. If your site is hosted somewhere else and you’re not sure who’s responsible for updates, that’s worth finding out this week. If you’d like a second pair of eyes, send us a message and we’ll check your version and look for the warning signs above.

CVE-2026-119977 FAQ

On WP Engine? A separate change on November 5 and 6 replaced the security keys in every site’s wp-config.php and stopped FluentSMTP from sending email. Here’s how to tell if the WordPress salts change broke your site’s email.

What should you do today?

Check your WordPress version, install 7.1.4 or the patched release for your branch, and look for the warning signs if your site was behind. It’s a short job for most sites, and it closes a hole attackers are already trying to use.

If you’d rather hand it off, talk to us. We’ll check your site, tell you what we find, and fix it.