On 3 November 2026, CISA added a WordPress vulnerability, CVE-2026-119977, to its Known Exploited Vulnerabilities catalog and gave federal agencies until 6 November to fix it. The flaw is a race condition in the way WordPress core updates itself, and it can let an unauthenticated attacker run code on the server while an update is in progress. WordPress fixed it in version 7.1.4 on 28 October, and within days Wordfence reported blocking 13,095 attacks against it in a single 24-hour period (BleepingComputer, November 2026).
Your own web team can patch its sites this week. The harder part is the vendor websites, customer portals, and agency-run microsites built on WordPress that sit outside your control, and the odd detail of this flaw is that the update meant to fix it is the moment it can be exploited.
What is CVE-2026-119977?
CVE-2026-119977 is a time-of-check to time-of-use race condition (CWE-367) in the WordPress core upgrade process. During a full-package update, WordPress unpacks the new release into a temporary staging location. Where that location is predictable and reachable from the web, an attacker who times requests correctly can execute code on the server before the update finishes, with no login required.
Picus Security researcher Umut Bayram reported the flaw (Picus Security, November 2026), and WordPress described it in its release notes as “a weakness in the WordPress upgrade process” that can lead to remote code execution during the upgrade window (WordPress.org, October 2026).
The severity ratings disagree, and that is worth knowing before you set a deadline. Wordfence, which assigned the CVE, scores it 8.1 (High) on CVSS 3.1, with high attack complexity because the attacker has to hit a narrow window. The WordPress project’s own advisory rates the same issue Low. But CISA’s listing settles the practical question, because attackers are already trying it.
Is the WordPress vulnerability being exploited?
Yes. CISA confirmed active exploitation when it added CVE-2026-119977 to the KEV catalog on 3 November 2026, and Wordfence’s firewall blocked 13,095 attacks against it in 24 hours, as reported on 4 November. Those are blocked attempts on sites Wordfence protects. No public source has yet stated how many sites were actually compromised.
| Date (2026) | What happened |
|---|---|
| 28 October | WordPress releases 7.1.4 and backports the fix to every branch back to 4.7 |
| 31 October | CVE-2026-119977 is published, scored 8.1 by Wordfence |
| 3 November | CISA adds the flaw to its Known Exploited Vulnerabilities catalog |
| 4 November | BleepingComputer reports 13,095 blocked attacks in 24 hours |
| 6 November | Deadline for US federal civilian agencies to patch |
Which versions are affected, and how do you patch?
Every supported WordPress branch from 4.7 to 7.1.3 needed the fix. The patched releases include 7.1.4, 7.0.8, 6.9.11, and 6.8.12, and older branches back to 4.7.39 received their own patched builds. Sites on 4.6 or earlier no longer receive security updates at all, which makes them a finding on their own (aicybr, November 2026).
Sites with automatic background updates should already be on a fixed release, since WordPress starts those updates by itself. Confirm it anyway by checking the version in the dashboard or with wp core version, and update by hand anything that is behind.
Is patching enough?
Patching closes the flaw for future updates. It tells you nothing about the update that installed the fix. According to Picus, the first update from an unpatched release to 7.1.4 is still exposed, because the old extraction code does the unpacking. A site that moved to a fixed release after 28 October went through exactly the moment the flaw describes.
For sites that have not updated yet, Picus recommends blocking web access to the wp-content/upgrade/ folder first, or updating from outside the web root.
For any site that matters, run wp core verify-checksums to compare core files with the official release, then look at web server logs around the update time for requests to upgrade staging paths and for PHP files nobody created. A clean checksum covers core only, so review plugins, themes, and uploads, and look for unfamiliar administrator accounts. A request to a staging path is a lead to investigate, not proof of compromise.
Why is WordPress a third-party risk?
A large share of the web runs on WordPress, and much of it belongs to your suppliers. Your payroll provider’s customer portal, the agency that runs your event microsite, the law firm’s client extranet, and the small software vendor’s documentation site may all run it, often hosted by yet another company. Each one sits on someone else’s patching schedule and outside your logs.
Most of those sites hold little of your data. Some do, through form submissions, document uploads, or a login your staff reuse elsewhere. A vendor site compromised during its update can also serve malicious scripts to your users, the same pattern that runs through many supply chain attack examples. The hosting company that runs those updates is often a fourth party you have never assessed.
So context decides the workload. A brochure site with no login is a low-priority email. A vendor portal where your team uploads contracts or customer files is a call this week. Ranking vendors by the data and access each relationship carries is what lets a small third-party risk team answer a widespread vulnerability without emailing every supplier at once.
What should security and risk teams do now?
Treat CVE-2026-119977 as a third-party question as well as a patching job, and work the list in order of what each vendor’s site can touch. Most vendors will have patched by now, so the useful work is finding the few sites that hold your data, getting dated answers about their last update, and watching those vendors closely for a few weeks.
- Find the WordPress sites that matter. Start with vendor portals, extranets, and agency-run sites that collect your data or hold your staff’s logins. External attack surface scanning or a short questionnaire answer will tell you which ones run WordPress.
- Ask three questions in writing. Which WordPress version each site runs today, when it moved to a fixed release, and whether the vendor checked core file integrity and logs around that update.
- Close your own gaps. Patch every WordPress site your organization owns, including the forgotten campaign and regional sites, and run the same checks on them.
- Watch for the follow-on. Keep continuous monitoring on the vendors whose sites carry your data for defacements, injected scripts, and breach disclosures over the coming weeks.
- Record the answers. Add the platform behind each vendor site to your inventory, so the next web platform flaw takes hours to scope. The third-party incident response playbook covers the rest of the sequence.
WordPress runs on PHP, so if your team worked through PHP2Shell and your third parties last month, the same vendor list is a good place to start.
Panorays continuously monitors your vendor ecosystem and flags cyber events, such as an exploited vulnerability, tied to the suppliers you depend on. See how it works.
What should WordPress site owners do?
Update to the fixed release for your branch today, and confirm automatic background updates are switched on for core security releases. Then run the checksum and log review above for the update you have just made, change administrator passwords if anything looks wrong, and ask your hosting provider whether it saw attack traffic against your site.
WordPress Vulnerability FAQs
What is CVE-2026-119977?
CVE-2026-119977 is a race condition in the WordPress core update process that can let an unauthenticated attacker run code on the server during a full-package upgrade. It affects WordPress releases up to 7.1.3, was fixed in 7.1.4 and matching releases on older branches on 28 October 2026, and is scored 8.1 (High) by Wordfence.
Is the WordPress vulnerability being exploited?
Yes. CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on 3 November 2026, which means it has evidence of exploitation in the wild. Wordfence reported blocking 13,095 attacks against the flaw in 24 hours. No public source has said how many sites were successfully compromised.
Is my WordPress site affected if it auto-updated?
A site that auto-updated to a fixed release is protected against future attempts. Because the flaw sits in the update process itself, the update that installed the fix could still have been targeted while it ran. Verify core checksums and review logs from around the update time, starting with the sites that hold customer data or logins.
Why does WordPress rate the vulnerability Low when CISA lists it?
WordPress has not explained its Low rating publicly. Wordfence’s 8.1 score already marks the attack as high complexity, since the attacker must win a timing race, but weighs the full impact of code execution without a login. CISA’s catalog records that attackers are using the flaw, and for prioritization that matters more than either label.
Which of my vendors run WordPress, and what should I ask them?
Start with vendors whose sites collect your data or hold your staff’s logins: portals, extranets, and agency-run sites. Ask which WordPress version they run, when they patched, and whether they checked file integrity around the update. Record the answers in your vendor inventory for the next web platform flaw.
