CISA put WordPress Core flaw CVE-2026-119977 on its Known Exploited Vulnerabilities list on November 3, 2026, confirming that attackers already abuse a bug WordPress patched six days earlier, BleepingComputer reported. Federal civilian agencies have until Friday, November 6 to fix it under Binding Operational Directive BOD 26-04.
The bug is a time-of-check to time-of-use race condition in the way WordPress unpacks a full-package core update. It carries a CVSS 3.1 score of 8.1 and affects WordPress 4.7.0 through 7.1.3. The fix ships in WordPress 7.1.4, released October 28. The awkward part: the hole opens during the update itself. Teams that already run a CISA KEV patch workflow should treat this listing as a live test of it.
This analysis covers how the WordPress vulnerability works, what the exploitation evidence shows, which mitigations hold up, and what the CISA KEV listing means for hosts, agencies and security vendors. Where a figure rests on a single report, the text says so.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
How CVE-2026-119977 Works: A Race Inside the Updater
When WordPress applies a full-package core upgrade, it unpacks the new release into a staging area beneath wp-content/upgrade. According to write-ups from technine and DEV Community, that staged copy includes the installer file setup-config.php, and on many server setups the directory answers over HTTP. A visitor with no login who requests the staged installer at the right moment can push it toward PHP code execution before WordPress cleans up.
The WordPress security team described it on October 28 as “A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window.” The same notice told site owners: “Because this is a security release, it is recommended that you update your sites immediately.” Both lines appear in the BleepingComputer report.
The staging directory problem
Predictability is the weakness. If an attacker can guess the path and the file names, no stolen credential, plugin bug or phishing step is needed. The target is WordPress Core itself, so the usual advice to prune plugins does nothing here.
Why timing decides everything
Wordfence’s lab testing found the staging directory normally exists for only a few seconds, according to the DEV Community analysis. One stray request almost never lands inside that window. A script that polls the path around the clock does. BleepingComputer describes high-complexity attacks, and that fits: the exploit works through persistence rather than cleverness.
An 8.1 score undersells the urgency. CVSS measures severity, not whether anyone is attacking right now, which is the gap that any comparison of EPSS, CVSS, CISA KEV and SSVC triage keeps returning to. A KEV entry settles the question the score leaves open.
Affected Versions and the WordPress 7.1.4 Fix
Public records put the affected range at WordPress 4.7.0 through 7.1.3. The Canadian Centre for Cyber Security phrases it differently in advisory AV26-1117: any Core version before 7.1.4 is affected. The two descriptions agree in practice. If a site has not moved to 7.1.4 or the matching branch fix, assume it is exposed.
WordPress 7.1.4 is a security release that, per Wordfence’s write-up of it, fixes 22 security vulnerabilities, so patching closes more than this one hole. Umut Bayram, a Picus Security researcher, reported the flaw, and the public CVE record tracks it. The DEV Community analysis says the fix randomizes the staging directory, adds an index guard and stops unsafe promotion of staged configuration data.
Older branches get the fix too. Reporting says backports reach back reportedly from 7.0.8 down to 4.7.39, while WordPress 4.6 and older receive no security fixes at all. Owners of those very old sites face a real upgrade, not a point-release patch. Technine adds that only the latest major branch is actively supported, so branch backports are a bridge and not a destination.
One more version fact keeps readers from chasing the wrong release. WordPress 7.1 shipped August 19, and WordPress 7.2 is still in development, with Beta 4 announced November 3. No 7.2 final exists yet. The patched line today is 7.1.4.
Timeline: October 28 to the November 6 Deadline
The sequence is short, which is the point. Six days separated the patch from the KEV listing, and three days separate the listing from the federal deadline. The table below sticks to dates confirmed on official or multiply sourced pages.
| Date (2026) | Event | Why it matters |
|---|---|---|
| October 28 | WordPress releases 7.1.4 as a security release | First patched build for the upgrade-window flaw |
| October 31 | Public CVE records describe CVE-2026-119977 as affecting Core through 7.1.3 | The bug gets a trackable identifier and a CVSS 8.1 rating |
| November 3 | CISA adds the flaw to the KEV catalog on evidence of active exploitation | Confirms real attacks, not a lab proof of concept |
| November 3 | Canada’s Cyber Centre publishes advisory AV26-1117 | International defenders get a second official alert |
| November 3 | WordPress announces 7.2 Beta 4 | Next major branch still in testing, not a patch option |
| November 4 | CISA updates its alert | Signals the agency still treats the issue as live |
| November 6 | Federal civilian agencies must remediate under BOD 26-04 | Three days from listing to deadline |
A November 6 date marks a compliance deadline. It does not mark the day the bug was found or fixed. Private-sector admins should read it as the latest sensible moment, not a grace period.
What Wordfence Has Seen So Far
Attack counts vary by report because each one measures a different window. Technine’s summary of Wordfence data says the firewall vendor shipped a rule for paid customers within hours of the release and saw a matching request about nine minutes later. It reports more than 18,500 requests aimed at staged installer paths in the first 21 hours.
The totals then climbed. On October 30, The Hacker News, citing Wordfence, reported 62,969 blocked attempts in 24 hours, per the same technine piece. BleepingComputer later quoted a weekend Wordfence advisory update saying the firm “blocked 13,095 attacks targeting this vulnerability in the past 24 hours.” The DEV Community analysis says Wordfence still blocked more than 12,600 exploit attempts per day as of November 4.
Treat these as probing volume, not as a body count. Neither Wordfence nor The Hacker News has stated confirmed successful compromises tied to this flaw, according to technine. The DEV Community analysis lists use in ransomware campaigns as unknown. It also says two of the largest sources repeatedly polled small groups of sites for about 14.5 hours, behavior that matches an attacker hunting for the brief upgrade window. Other sources tried variations of staging-directory and version names.
A firewall caveat matters too. Technine relays Wordfence’s warning that a request aimed straight at a staged PHP file may slip past a plugin-level firewall unless Extended Protection or equivalent early loading is on. The free-tier version of the rule is delayed until November 27, which leaves free users to rely on the patch itself.
CISA’s Deadline and Why BOD 26-04 Reaches Beyond Agencies
BOD 26-04 binds only Federal Civilian Executive Branch agencies. CISA still urged all network defenders, private companies included, to prioritize the fix, BleepingComputer reported. The agency’s warning, as quoted there: “This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise.”
CISA’s current notice, as summarized in reporting, directs agencies to prioritize KEV flaws on publicly exposed assets that could hand an attacker total control. A WordPress site on the open internet fits that description. Deadlines under the directive have run tight all fall, as in the case of the first MCP flaw CISA flagged in LiteLLM, where BOD 26-04 set the clock.
For companies outside government, the KEV catalog doubles as a free threat feed. Insurers, auditors and enterprise customers may ask whether a firm patched KEV entries by the federal date. A WordPress marketing site that sits unpatched past November 6 can become a questionnaire problem long before it becomes an incident.
Patching Without Opening the Window
The DEV Community analysis states the dilemma plainly. Clicking Update Now opens the window attackers poll for. Delaying the update leaves the site exposed to all 22 vulnerabilities in 7.1.4 for longer. Its conclusion: for most site owners, updating immediately is still correct. If you control the server or the CDN layer, block web access to the staging path first, then update.
First confirm where you stand. These WP-CLI commands report the installed version and any pending update, then apply a same-branch security release and check Core file integrity:
wp core version
wp core check-update
wp core update --minor
wp core verify-checksumsThe –minor flag keeps a site on its current branch and applies the matching security release, which suits legacy sites that cannot jump majors today. To shield the staging path during the update, deny HTTP requests to it at the web server. This nginx rule does it:
location ^~ /wp-content/upgrade/ {
deny all;
return 403;
}On Apache, put the equivalent in the virtual host rather than in a .htaccess file inside the upgrade folder, because WordPress recreates that folder during updates and a local file can vanish:
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>Both rules mitigate the race. Neither replaces the patch. Remove them only after the site reports 7.1.4 or its branch fix, and test that the update still completes, since some hosts run their own update tooling.
Mitigation Options Compared
Not every option fits every team. The table shows what each approach does and where it stops.
| Option | What it does | Strength | Limit |
|---|---|---|---|
| Update to 7.1.4 or branch fix | Removes the vulnerable upgrader behavior | The only complete fix, also covers 22 vulnerabilities | On unpatched builds the update itself runs through the window |
| Deny HTTP to wp-content/upgrade | Stops outside requests reaching staged files | Works on any WordPress version with no plugin dependency | Needs server or CDN access, a stopgap only |
| Paid Wordfence rule | Blocks matching requests at the application layer | Shipped within hours of the release | Can miss direct PHP requests without Extended Protection |
| Free Wordfence rule | Same rule, delayed | No cost | Arrives November 27 per technine, after the federal deadline |
| Managed host forced update | Host pushes 7.1.4 across customer sites | No admin effort | Needs written confirmation, do not assume |
| Wait for auto-update | Relies on WordPress background updates | Costs nothing | Background updates can fail silently |
The practical order is clear. Patch first, shield the path if you can, and treat firewall rules as cover while the update propagates. Anyone relying on a host should ask for a yes-or-no answer on whether every site runs 7.1.4 or the right backport.
How to Check Whether a Site Was Hit
Sites that stayed unpatched after October 28 deserve a look backward. Start with web server logs. Requests to a staged setup-config.php, or to unexpected PHP files under wp-content/upgrade, around the time of a recent core update are the clearest sign of probing. This search covers rotated and compressed logs:
zgrep -hE "wp-content/upgrade/.*\.php" /var/log/nginx/access.log* | sort | uniq -c | sort -rn | headThen hunt for persistence. Unexpected administrator accounts, plugins nobody installed and PHP files nobody placed all warrant a malware scan and a wider investigation. Run wp core verify-checksums to flag modified Core files, and list administrators with wp user list –role=administrator. A scanner helps with the rest, and a walkthrough of how to use WPScan to scan WordPress covers a repeatable routine.
Keep expectations calibrated. Probe volume is high, yet public reporting has not named confirmed victims. Absence of evidence is not safety, but it does mean most owners are checking for trouble, not cleaning up a known breach.
WordPress Core on the KEV List, Again: The 2026 Pattern
This is not the first WordPress Core scare of 2026. In July the security team patched a chain dubbed wp2shell, which combines a REST API batch-route confusion bug (CVE-2026-63030) with an SQL injection flaw (CVE-2026-60137), BleepingComputer recounts. Public exploits appeared one day after the patches, and attackers began breaching unpatched servers a few days later to drop webshells and install malicious plugins. A Chinese-speaking threat actor reportedly weaponized the chain in September to pull data from more than 18,500 backend records belonging to small businesses and government bodies.
September brought another, WordPress CVE-2026-87902, which attackers exploited within hours of disclosure. Then October added the runtime layer. The PHP project shipped 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical flaws, CVE-2026-109618 and CVE-2026-109619, known as php2shell, and CISA added both to KEV on October 26. Coverage of the NSA warning on the PHP flaw shows how far the alarm spread.
| Event | Layer | Bug class | Fix |
|---|---|---|---|
| wp2shell (CVE-2026-63030 plus CVE-2026-60137) | WordPress Core | REST API batch-route confusion chained with SQL injection | July Core patch |
| php2shell (CVE-2026-109618, CVE-2026-109619) | PHP runtime | Memory corruption and stale internal request-state flaws | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
| CVE-2026-119977 | WordPress Core upgrader | Time-of-check to time-of-use race condition | WordPress 7.1.4 and branch backports |
The three events sit at different layers of the same stack, yet one habit ties them together: attackers move within days of a patch. Wordfence said on October 28 that it knew of no WordPress site compromised through php2shell. That statement predates the new flaw and covers a different bug, so it offers no comfort here.
A Crowded KEV Fall for Defenders
CISA’s own alert pages show a steady drumbeat of additions. The agency listed four vulnerabilities on October 14, one on October 15, six on October 20 and two on October 26, each on evidence of active exploitation. The WordPress entry on November 3 made one more. Defenders now triage a new batch most weeks.
The mix matters. Most recent entries hit edge devices and enterprise platforms, such as two more Ivanti Connect Secure zero-days with a November 13 CISA deadline and a GitLab flaw rated CVSS 10.0 that joined KEV. WordPress sits in a different bucket. It runs on shared hosting, small agency servers and unattended marketing sites that no one assigns to a security team. Edge appliances get an on-call engineer. Many WordPress installs get nobody.
That gap explains why a CVSS 8.1 flaw earns a federal deadline while attackers still scan the open internet for it. High-complexity attacks lose their complexity when automation does the waiting.
Who Needs to Act, and What to Do First
- Federal civilian agencies: remediate by November 6 under BOD 26-04 and record the fixed version for each public WordPress property.
- Self-hosted site owners: run wp core version, update to 7.1.4 or the matching branch release, and deny HTTP access to wp-content/upgrade while the update runs.
- Agencies managing many client sites: inventory every install, including forgotten staging and microsites, before pushing updates in bulk.
- Managed WordPress customers: ask the host in writing whether all sites run a fixed build and whether web access to the staging path is blocked.
- Owners of WordPress 4.6 or older: plan a full upgrade. Those branches receive no security fixes, so no patch exists to apply.
- Security teams: add CVE-2026-119977 to the KEV watchlist, hunt in logs for staged-installer requests, and check for new admin users and unknown plugins.
The list favors speed over elegance. Version inventory comes first because every later step depends on knowing which sites are still exposed.
Market Impact: Hosts, Firewalls and Scanners
Managed WordPress hosts gain a sales argument. A bug that triggers during updates rewards providers who control the server layer and can block the staging path before pushing a release. Shared-hosting customers who patch by hand have less leverage, and many will ask whether their plan includes forced updates.
Firewall vendors face a pricing test. Wordfence shipped its rule to paying customers within hours and holds the free-tier version until November 27, per technine. The company has also announced a price increase coming December 3, 2026. Speed-for-payment is a legitimate model, yet it hands critics an easy headline whenever exploitation starts before the free rule lands.
Vulnerability-management vendors benefit from the listing. Tenable already carries a public CVE-2026-119977 page, and scanner plugins will add checks within days. Buyers weighing platforms can start with a look at Tenable, Qualys and Rapid7 in vulnerability management, though none of them replaces an owner who knows where every WordPress install lives.
Hosted site builders also get a talking point. The recurring Core exposure features in any WordPress vs Webflow comparison that weighs security upkeep against flexibility. A self-patching SaaS platform avoids this class of race, though it trades away the control that makes WordPress popular. Whether buyers switch over one bug is doubtful. Whether they add a patching clause to hosting contracts is likelier.
Five Predictions for the Next 30 Days
These are analyst judgments, not reported facts.
- Scanning will peak around the deadline. Public KEV listings tend to draw copycat scanners, so expect probe volume to stay high through mid-November, even as the patched share of sites rises.
- Hosts will force updates. Managed providers will push 7.1.4 and branch fixes to customers who never clicked anything, and some will block the staging path by default.
- WordPress will harden the updater. The 7.1.4 fix already randomizes the staging directory. A move to staging outside the web root in a later release is a reasonable bet, though no such plan has been announced.
- The ransomware flag may flip. Use in ransomware campaigns is listed as unknown today. KEV entries sometimes change that field later, so watch the catalog entry for an update.
- Researchers will hunt sibling bugs. Attention on installer and upgrader paths will turn up related race conditions in plugins and other CMS platforms, widening the story beyond WordPress.
For broader context on how these listings shape security work, see the wider cybersecurity coverage.
Frequently Asked Questions About CVE-2026-119977
What is CVE-2026-119977?
It is a time-of-check to time-of-use race condition in WordPress Core’s upgrade process. It carries a CVSS 3.1 score of 8.1 and can let an unauthenticated attacker run code on the server during the brief window when an update is unpacking.
Which WordPress versions are affected?
Public records list WordPress Core 4.7.0 through 7.1.3. Canada’s Cyber Centre says any version before 7.1.4 is affected. WordPress 7.1.4 fixes it, and backports for older branches reportedly exist.
Is the flaw actually being exploited?
Yes. CISA added it to the KEV catalog on November 3, 2026 on evidence of active exploitation. Wordfence has reported thousands of blocked attempts, though public reporting has not confirmed specific compromised sites.
When is the federal deadline?
Federal Civilian Executive Branch agencies must remediate by Friday, November 6, 2026 under BOD 26-04. The directive does not bind private companies, but CISA urged them to patch too.
Does updating WordPress open the vulnerable window?
On an unpatched build, the update does pass through the window. Even so, most site owners should update immediately, because delay leaves the site exposed to 22 fixed vulnerabilities. If you control the server, block HTTP access to wp-content/upgrade first.
Do I need WordPress 7.2?
No. WordPress 7.2 is still in beta, with Beta 4 announced November 3. Install 7.1.4, or the fixed release for your current branch, today.
Are WordPress.com sites affected?
The advisories address the open-source WordPress Core software. WordPress.com is a separate hosted service, and none of the sources reviewed here describe its status, so check with the provider directly.
