WordPress 7.1.4 Security Update: Update Now, CISA Confirms Attacks

Update WordPress now. On October 28, 2026, the WordPress project shipped WordPress Core 7.1.4, a security release that patches a high-severity remote code execution (RCE) flaw in the software that powers a huge share of the websites on the internet. The bug is tracked as CVE-2026-119977 (CVSS 3.1 score: 8.1, High), and on November 3, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities (KEV) catalog after confirming it is being actively exploited in the wild. Federal civilian agencies have until November 6, 2026 to patch under CISA's binding directive — but every WordPress site owner, not just federal agencies, should treat that date as their deadline too.

If your site runs WordPress 7.1.0–7.1.3 or 7.0.0–7.0.7, this is not a "patch when you get a chance" update. According to the National Vulnerability Database (NVD) entry for the flaw, the vulnerability lets an unauthenticated attacker execute arbitrary code on a vulnerable server, with no login and no user interaction required. Below is what the vulnerability actually does, which versions are affected, why it's being exploited so fast, and exactly what to do about it.

What happened

WordPress 7.1.4 is a security-only release. In its own announcement, the WordPress project says the update fixes a dozen-plus issues, the first and most serious of which it describes as an "upgrade process weakness" that "can lead to remote code execution during the upgrade window," credited to researcher Umut Bayram. WordPress says fixes were backported to every branch still eligible for security support — which the post states reaches back "through 4.7" — and that sites with automatic background updates should already be patched.

That upgrade-process bug is CVE-2026-119977. It was assigned by Wordfence, which operates as a CVE Numbering Authority (CNA) for WordPress-ecosystem vulnerabilities, and is also catalogued under GitHub Security Advisory GHSA-4w3m-c66w-69mg. NVD published its record on October 31, 2026, three days after the patch shipped, and CISA's KEV addition followed on November 3 — a remarkably short window between disclosure and confirmed active exploitation.

The vulnerability: CVE-2026-119977

Per NVD's official description, "WordPress Core is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3. This is due to predictable, web-accessible staging paths used during full-package core upgrades. This makes it possible for unauthenticated attackers to execute code on the server during the upgrade window." NVD classifies the flaw as CWE-367, a Time-of-Check Time-of-Use (TOCTOU) race condition, with the following CVSS 3.1 vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H — network-exploitable, no privileges or user interaction needed, with full impact to confidentiality, integrity, and availability once triggered. The "high attack complexity" rating reflects the fact that an attacker has to win a race against a narrow timing window, not that the flaw is hard to find.

How the attack works

WordPress's "full-package" core update method — used for major-version upgrades and some automatic updates — works by downloading a complete copy of WordPress core, unpacking it into a temporary staging folder inside wp-content/upgrade/, and then swapping it into place. NVD's reference list points to the exact lines of code involved, in class-wp-upgrader.php, class-core-upgrader.php, and update-core.php.

The problem, according to the vulnerability's description, is that the staging directory's path was predictable and sat inside a web-accessible location for the duration of the unpacking process — which the NVD record calls "the upgrade window." Because that staged copy also includes WordPress's own installer script, an attacker who requests the right path at the right moment, before the swap completes, can potentially reach the staged installer and point it at a database server they control, effectively hijacking a brand-new WordPress install before the legitimate one finishes deploying. Because this all happens before any authentication layer is relevant, no account or credentials are needed — hence the "unauthenticated" rating and the full-severity confidentiality/integrity/availability impact in the CVSS vector.

WordPress 7.1.4 closes the hole by randomizing the staging directory name, adding an index guard against directory listing, and preventing unsafe promotion of staged configuration data — the same category of hardening security researchers recommend after any race-condition disclosure of this kind. For a broader look at how attackers structure multi-stage intrusions once they get an initial foothold like this, see our explainer on the APT lifecycle.

Affected and fixed versions

NVD's affected-configurations data lists every WordPress branch from 4.7 through 7.1 as technically vulnerable, which matches the WordPress security team's statement that the fix was backported "through 4.7." For the two most recent branches, the ranges that matter to most site owners are:

If you're not sure which branch your site is on, check Dashboard → Updates in wp-admin, or look at the version string in your site's <head> generator tag (if it hasn't been hidden). Hosts that manage WordPress core updates for customers — many managed-WordPress providers do — may have already pushed 7.1.4 automatically, but it's worth confirming rather than assuming, especially on self-managed VPS or dedicated-server installs.

Active exploitation and the CISA KEV listing

This flaw moved from "patched" to "actively exploited" unusually fast. WordPress published 7.1.4 on October 28, 2026; NVD's CVE record was published October 31; and CISA's KEV alert — titled "CISA Adds One Known Exploited Vulnerability to Catalog" — landed November 3, explicitly citing "evidence of active exploitation." NVD's own analyst notes (via its SSVC scoring data) likewise mark the vulnerability's exploitation status as "active" and its technical impact as "total."

Wordfence, the firm that discovered and assigned the CVE, publishes its own technical writeup of the flaw in its vulnerability intelligence database. Security researchers who track WordPress-targeted attack traffic reported that automated scanning for the vulnerable upgrade-staging paths began within hours of the 7.1.4 release — the kind of mass, opportunistic probing that's typical once a patch diff reveals exactly what was broken. The exact scale of attack traffic hasn't been independently confirmed by Pandromeda beyond CISA's own "active exploitation" determination, but the KEV listing itself is the clearest signal available: CISA only adds a CVE to the catalog when it has direct evidence of real-world attacks, not just theoretical risk.

CISA's Binding Operational Directive 26-04 requires federal civilian executive branch agencies to remediate catalog vulnerabilities by the stated due date — November 6, 2026, in this case — and to check whether systems were already compromised before patching. CISA also "strongly recommends" that all organizations, not just federal agencies, prioritize timely remediation of every KEV-listed vulnerability. Given how often WordPress underpins small-business sites, blogs, and non-profit infrastructure with no dedicated security team, this is exactly the kind of advisory that's easy to miss if you're not already watching for it. It's a similar pattern to another recent CISA KEV addition, the GitLab RCE flaw now under active attack, where mass exploitation followed almost immediately after public disclosure.

Who is at risk

The exploitation window is specifically tied to the moment a site performs a full-package core update — not to every WordPress site, all the time. That means risk is concentrated around:

• Sites that have not yet updated past 7.1.3 or 7.0.7 and are still scheduled or likely to run a full-package update soon (including via the admin dashboard's "Update Now" button, WP-CLI, or some managed-hosting update pipelines).
• Self-managed sites where automatic background updates are disabled — a common setting on sites with heavy custom code, where admins worry an auto-update will break a theme or plugin.
• Older installations that have been sitting on an outdated branch for a long time and are about to attempt a jump across several versions in one update.

WordPress's own guidance is that sites with automatic background updates enabled should already be running 7.1.4 (or the equivalent fixed release on their branch) without any action needed. If you manage updates manually, or you supervise a fleet of WordPress sites for clients, that's where the real exposure sits right now.

What to do now: remediation steps

1. Confirm your version. Log into wp-admin and check Dashboard → Updates, or check Dashboard → Updates → WordPress for your current core version against the affected ranges above.
2. Update immediately if you're on an affected version. Apply 7.1.4 (or 7.0.8, or your branch's backported fix release) via the dashboard, WP-CLI (wp core update), or your host's update tooling. Don't wait for an automatic background update if one hasn't already run.
3. Check wp-content/upgrade/ for anything that shouldn't be there. Because the flaw involves a staging directory under that path, site owners who are concerned about prior exposure should check for unexpected files, especially stray PHP files, left over from the update process, and remove anything that doesn't belong.
4. Review for signs of compromise before and after patching — new admin users you don't recognize, unfamiliar files in core directories, or scheduled tasks (cron jobs) you didn't create — consistent with CISA's guidance to check for prior compromise rather than assume a patch alone resolves an active-exploitation KEV entry.
5. If you manage multiple WordPress sites (agencies, freelancers, managed hosts), audit all of them now rather than one at a time — mass scanning tools don't discriminate by client size.
6. Keep automatic background updates enabled going forward unless you have a specific, documented reason not to; this class of vulnerability specifically targets the update process itself, and the sites least exposed going forward are the ones that patch fastest and most consistently.

None of this requires special security tooling — it's standard WordPress hygiene applied with urgency. If you're coordinating a broader vulnerability-management process across non-WordPress infrastructure too, our recent coverage of the Ivanti Connect Secure CISA-KEV patches is a useful parallel case study in triage priority.

Why this is such a big deal

WordPress is the content management system behind a large share of all websites on the internet — small businesses, newspapers, government portals, nonprofits, and plenty of enterprise marketing sites all run on it. That scale is precisely why a vulnerability in WordPress's own update mechanism is different from an ordinary plugin bug: it doesn't require a site to be running some obscure add-on to be exposed, only to be running core software that hasn't finished updating past a vulnerable point release. It's also why searches like "wordpress security update," "wordpress hacked," and "is my wordpress site safe" spike every time a core-level flaw like this surfaces — a huge number of site owners, many without a dedicated IT or security team, are suddenly trying to figure out whether they're affected.

It's also worth being precise about what the vulnerability does not do: it doesn't give attackers a permanent backdoor into every WordPress site by default, and it isn't exploitable outside the narrow window a full-package core update is actively unpacking files. That nuance matters for triage. A site that updated promptly, or that has been sitting on a non-vulnerable version all along, isn't at ongoing risk from this specific flaw. The urgency is about closing that update-time window everywhere it's still open — and about checking, per CISA's guidance, whether that window was already used against you before the patch landed.

The bottom line

WordPress still powers a huge share of the web, which is exactly why a flaw in its own update mechanism is so consequential: it's not a plugin edge case, it's core software running on everything from personal blogs to enterprise marketing sites. CVE-2026-119977 is now a confirmed, actively exploited, federally tracked vulnerability with a hard remediation deadline attached. The fix has existed since October 28. If your site hasn't picked it up yet, that's the only action item that matters today.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage