On 3 November 2026, CISA added a WordPress core bug to its list of vulnerabilities that attackers are actively using. Not a plugin, not a theme. Core WordPress, tracked as CVE-2026-119977. The odd part is where it lives: the update process itself. The moment you click "Update WordPress" is the moment a site can be attacked.
My own site runs on Blogger, so this one doesn't touch me directly. But plenty of small businesses, schools and news sites here in Nepal run WordPress, often on cheap shared hosting that nobody has logged into for months. If that's you, or a site you look after, here's what the bug is, which version fixes it and how to check a site in a few minutes.
Quick answer
Update to WordPress 7.1.4 (released 28 October 2026), or the latest security release on your branch, since the fix was backported to versions as old as 4.7. The bug is a race condition in the core upgrade process that can lead to remote code execution during the upgrade window, and CISA confirmed active exploitation on 3 November. After updating, check for files you didn't put there and plugins you didn't install.
What the bug actually is
WordPress describes it as a weakness in the upgrade process that can lead to remote code execution during the upgrade window. In plainer terms: when WordPress installs a full core update, it unpacks the new files into a temporary staging location before moving them into place. Reports say those staging paths were predictable and reachable from the web.
That creates a race. For a short time, there's a gap between WordPress checking a file and WordPress using it. An attacker who wins that race can swap in their own file and get their code run on your server. That's what "time-of-check to time-of-use", or TOCTOU, means.
It was reported by Umut Bayram of Picus Security, and the official note is in the WordPress 7.1.4 release post.
How serious is it?
The scores don't agree, which is worth knowing:
| Source | What they say |
|---|---|
| WordPress (GitHub advisory) | Low severity |
| Wordfence | CVSS 8.1, High |
| CISA | Added to the Known Exploited Vulnerabilities catalog on 3 November 2026 |
| Wordfence (via BleepingComputer) | Blocked 13,095 attacks on this bug in a single 24 hour period |
The attack is described as hard to pull off, because the attacker has to hit the exact moment an update runs. That's probably why WordPress rated it low. But CISA doesn't add bugs to its catalog on theory. It needs evidence of real attacks. And when thousands of attempts a day are being blocked, someone clearly thinks it's worth trying. I'd treat it as serious.
You can see the entry in CISA's 3 November alert and the full write-up on BleepingComputer.
It's not the only fix in 7.1.4
The same release fixed a long list of other problems, mostly stored cross-site scripting (XSS) in blocks, the Customizer, the Interactivity API and usernames, plus a way for logged-out visitors to discover unpublished Customizer changes. Two of the XSS bugs were reported by Anthropic. WordPress also updated its bundled root certificates after the eMudhra revocation.
So even if the race condition never hits your site, 7.1.4 is a worthwhile update on its own.
How to check and update a site
From the dashboard it's quick: Dashboard > Updates shows your version, and if 7.1.4 is available there's an Update to version 7.1.4 button. Sites with automatic background updates turned on should already have it. Check anyway, because many hosts and security plugins switch auto-updates off.
If you have SSH access and WP-CLI, this is faster, especially for several sites:
wp core version
wp core update
wp core verify-checksumsThe last command compares every core file with the official copy and lists anything that's been changed. That's your quickest sign that something was tampered with.
Can't use 7.x? WordPress says the security fixes were backported to every branch still eligible, all the way back to 4.7. Some of those backports were still being rolled out when 7.1.4 shipped, so check the release post for your branch.
After you update: look for signs of trouble
Updating closes the hole. It doesn't remove anything an attacker already left behind. This year has already seen another WordPress chain, wp2shell, used to plant web shells and steal data, so I'd do a quick check on any site that sat unpatched:
- Run the checksum command above and look at any core file it flags.
- Look for PHP files where they don't belong, especially inside
wp-content/uploads. Uploads should be images and documents, not code. - Check the plugins and users lists for anything you don't recognise, such as a new administrator account.
- Look at
wp-config.phpand its modified date. Reports say an attacker could replace it during the race. - Change admin passwords and the database password if anything looks off, and restore from a clean backup if you find a web shell.
find wp-content/uploads -name "*.php"
wp user list --role=administrator
wp plugin listA few lessons from this one
- Keep automatic core updates on. For minor and security releases, the risk of an update breaking something is much smaller than the risk of running a known-exploited bug.
- Don't forget the old sites. The site most likely to be hit is the one nobody remembers: a campaign page from 2021, a client's old site, a test copy on a subdomain.
- "Low" doesn't mean safe. Vendor severity tells you how hard a bug is to exploit in theory. CISA's catalog tells you whether people are doing it anyway.
- Put a firewall in front. A web application firewall, whether Cloudflare in front of the site or a security plugin, blocked a lot of these attempts before sites were patched. I explain how to put a site behind Cloudflare in this Cloudflare custom domain guide.
AI tools are finding more bugs in big projects, and fixes are arriving faster than ever. I wrote about the same trend in OpenAI's AI finding 948 Linux kernel bugs. The practical result for site owners is simple: update more often than you used to. If you run several sites and want someone to sort out updates, backups and a firewall properly, have a look at my services.
Frequently asked questions
What is CVE-2026-119977 in WordPress?
It is a time-of-check to time-of-use race condition in the WordPress core upgrade process that can lead to remote code execution during the upgrade window. CISA added it to its Known Exploited Vulnerabilities catalog on 3 November 2026.
Which WordPress version fixes CVE-2026-119977?
WordPress 7.1.4, released on 28 October 2026. The fix was also backported to older branches still eligible for security updates, back to 4.7, so update to the latest release on your branch.
Is CVE-2026-119977 being exploited?
Yes. CISA confirmed active exploitation on 3 November 2026, and Wordfence reported blocking 13,095 attacks targeting the bug in one 24 hour period.
How do I check if my WordPress site was compromised?
Run wp core verify-checksums to find changed core files, look for PHP files inside wp-content/uploads, and check for unknown plugins or administrator accounts. If you find a web shell, restore from a clean backup and change all passwords.
Will WordPress 7.1.4 install automatically?
Sites with automatic background updates enabled should update on their own. Many hosts and security plugins turn this off, so check Dashboard, Updates to confirm the version.