On November 3, 2026, CISA, the US cybersecurity agency, added CVE-2026-119977 to its catalog of actively exploited vulnerabilities. The flaw sits in the WordPress core update process and lets an attacker with no login run code on the server while the update is in progress. The fix shipped on October 28 in WordPress 7.1.4. Being listed in the catalog means the agency has evidence of real exploitation, not just a proof of concept.
The window opened by the update itself
According to the NVD record, the US government's public vulnerability database, the flaw affects versions 4.7 through 7.1.3. When WordPress runs a core update with the full package, it stages the new files in predictable, web-accessible paths. Anyone who knows the path and gets the timing right can execute code before the update finishes. It is a race condition: the system checks a file at one moment and uses it at the next, and the attack happens in between.
Wordfence, which registered the CVE, scores it 8.1 out of 10. The score treats attack complexity as high, because the attacker has to hit that window, but it requires no account and no action from anyone on the site.
The 7.1.4 announcement describes the problem as "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window". The same release fixed more than ten other flaws, most of them stored XSS reachable by users with the contributor role or higher.
Who needs to check
Any self-hosted WordPress from 4.7 to 7.1.3 is in scope. The project backported the fixes to every branch that still receives security updates, back to 4.7. The WordPress.org update API currently offers, besides 7.1.4, versions such as 7.0.8, 6.9.11 and 6.8.12 for sites on older branches. The announcement itself notes that only the most recent version is actively supported; older branches get these security fixes and nothing more.
The risk is higher where many sites are updated manually and infrequently: agencies with a client portfolio, companies running several corporate sites, installs nobody has reviewed since launch. There, core updates tend to run late, and every update started from a vulnerable version opens the window the CVE describes.
What to do now
The November 6 deadline set by CISA binds only US federal agencies. For everyone else the practical reference is the same: the flaw is already being exploited, so the fix should not wait for the next maintenance window.
- Confirm the version of each install. Either 7.1.4 or the fixed release of the branch in use counts, according to the WordPress.org API list.
- Check whether automatic background updates are on. They apply security releases without intervention, but they may be off, for example on sites deployed through Git or on hosts that control the core version.
- Review sites that ran a core update while vulnerable. CISA flagged the entry as requiring forensic triage, which for federal agencies means investigating beyond applying the fix. For a private site, my reading is that it is worth checking for PHP files created or changed around the date of the last update, and for unusual requests in the same period.
What the advisories do not say yet
CISA lists the flaw's use in ransomware campaigns as "unknown", and none of the public advisories says how many sites were attacked or how the attacks were observed.
It is also unclear whether the update to 7.1.4 itself, run from a vulnerable version, opens the window one last time. The description refers to the update code of the affected versions, and that is the code that runs when the site updates itself. Until the project clarifies this, it makes sense to update the most exposed sites first and watch the logs during and right after the update.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
