The moment a WordPress site updates itself is meant to be the moment it gets safer. A newly disclosed flaw shows that the update itself can be a short opening for attackers. WordPress has shipped security release 7.1.4, which fixes what the project calls "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window." The bug is tracked as CVE-2026-119977. On November 3 the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities (KEV) catalog and gave federal agencies until November 6 to act.
WordPress recommends updating immediately. The same release also fixes a long list of stored cross-site scripting bugs and updates the root certificates bundled with WordPress. The questions below cover what defenders need to know.
What exactly is broken?
The National Vulnerability Database (NVD) record says the problem appears during full-package core upgrades, when WordPress downloads and unpacks a complete new copy of itself instead of applying a smaller partial update. During that process WordPress uses temporary "staging" locations, and the record describes them as "predictable" and "web-accessible." The result, in NVD's words, is that "unauthenticated attackers can execute code on the server during the upgrade window."
CISA's catalog entry names the weakness CWE-367, a time-of-check time-of-use (TOCTOU) race condition. In plain English, a TOCTOU bug happens when software checks something and then acts on it a moment later, and in that gap an outsider can change things. Here, the gap is the stretch of time during an upgrade when files sit in a staging location an outsider can predict and reach over the web. The sources describe the impact and the root cause. They do not publish exploitation details, and this article does not either.
WordPress credits the report to researcher Umut Bayram. The CVE was assigned by Wordfence, which acted as the CVE Numbering Authority (CNA). Wordfence also published its own write-up, but ZeroDayFeed could not read that page, so nothing here relies on it.
How serious is it?
The CNA scored the flaw 8.1 (High) under CVSS 3.1. The vector shows network access, no privileges and no user interaction needed, and high impact on confidentiality, integrity and availability. It is rated high complexity, which fits a race condition: an attacker has to strike while an upgrade is actually running, not at any time they like.
That complexity rating does not mean the bug is only theoretical. CISA's coordinator assessment in the NVD record, dated November 3, lists exploitation as "active" and technical impact as "total." It also lists the flaw as not automatable, which suggests mass, push-button exploitation is less likely than targeted attempts. The KEV entry lists known ransomware use as "Unknown." Neither CISA nor NVD names a threat actor, and ZeroDayFeed is not attributing the activity to anyone.
NVD lists the record as "Undergoing Analysis," so NIST's own scoring may still be added or changed.
Which versions are affected?
According to NVD, every WordPress core release from 4.7 through 7.1.3 is affected. The record lists affected ranges branch by branch. Examples include releases up to 7.0.7, 6.9.10 and 6.8.11 on their branches.
WordPress says the fixes have been backported to all branches still eligible for security fixes, going back to 4.7, though it describes those backports as still in progress. The sources reviewed for this article do not list the exact patched version number for every older branch. Admins on older branches should check WordPress's release channels for their branch's update and not assume a particular number.
What else is in 7.1.4?
The upgrade-window flaw is the headline, but the release announcement lists a lot of other fixes:
- Multiple stored XSS bugs in the Interactivity API, Customizer selective refresh, the Categories block, the playlist and image blocks, the comments-pagination blocks, user logins, and privacy data removal requests. Stored XSS lets attacker-supplied script be saved on the site and run in other visitors' or admins' browsers.
- A stored denial-of-service issue in the Interactivity API.
- Unauthenticated discovery of unpublished customizer changesets, meaning draft site changes could be found by people who should not see them.
- A notes read-access issue.
- Updated bundled root certificates after the eMudhra revocation. WordPress ships its own certificate bundle for verifying outbound HTTPS connections, and this update keeps that bundle in step with the revocation.
WordPress also says the next major release, 7.2, is planned for December 8.
Why the federal deadline is so short
This entry gives agencies three days, from November 3 to November 6. The required action in the catalog cites Binding Operational Directive 26-04 and is flagged for forensic triage. In other words, CISA expects agencies to patch and to check whether they were already compromised. The directive is aimed at federal agencies, but contractors and private organizations running WordPress should treat it as a strong hint to do the same.
What It Means for Defenders
Who is affected: Anyone running self-managed WordPress core from 4.7 through 7.1.3, per NVD. That includes small-business sites, marketing sites run by IT teams, and the many agency and contractor sites built on WordPress.
What to patch:
- Update to WordPress 7.1.4 if you are on the 7.1 branch. WordPress calls it a security release and recommends updating immediately.
- If you run an older branch, apply that branch's security backport. WordPress says backports reach all eligible branches back to 4.7 and are still in progress, so keep watching if yours has not arrived yet.
- Sites with automatic background updates enabled should get the fix on their own. Check the version on each site; do not assume it updated. Managed hosts and multisite fleets deserve a manual inventory.
What to check:
- CISA lists exploitation as active and attaches forensic triage to its required action. Patching closes the hole but does not undo any earlier compromise. Review web server and application logs around past core upgrade times, since the flaw is tied to the upgrade window. Look for unexpected files in the WordPress installation, unfamiliar admin accounts, and changes to core, theme or plugin files you did not make.
- If you find signs of compromise, handle it as an incident, not just a patch job. Rebuild from known-good sources where possible.
What to rotate: The sources do not give rotation guidance specific to this flaw. Still, code execution on the server would normally expose anything the web server can read, including database credentials and secret keys in the site configuration. If triage turns up evidence of compromise, rotate those credentials and any API keys stored on the host.
Don't forget the XSS fixes: Sites that let contributors, commenters or other lower-privileged users post content benefit most from the stored XSS fixes in 7.1.4. That is another reason not to wait.
