Security notice

WordPress 7.1.4 fixes a flaw in its own updater. CISA says it is being exploited. Update today.

Last updated: Wednesday, November 4, 2026, 8:17 AM ETStatus: Exploited, per CISA (KEV, Nov 3). Update now.

On October 28, 2026, WordPress released version 7.1.4, a security release. It fixes "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window" (in plain words, a way for someone with no account to run their own code on your server while WordPress is updating itself), and WordPress recommends that you "update your sites immediately." On November 3, 2026, CISA, the US government's cybersecurity agency, added this flaw, now numbered CVE-2026-119977, to its Known Exploited Vulnerabilities (KEV) catalog "based on evidence of active exploitation." CISA has not said who was hit, and we found no public report naming a site that was taken over. CISA's November 6 deadline applies to US federal agencies, but CISA encourages every organization to prioritize KEV flaws. Before that, on October 29, security firm Wordfence said attackers were already trying to exploit this flaw: it reports more than 18,500 requests aimed at it in the first 21 hours, and The Hacker News reports, quoting Wordfence, 62,969 blocked attacks in 24 hours. Those figures count attempts. The attack only works if someone hits a narrow window of seconds while a full WordPress update is unpacking, so updating now does not tell you whether an earlier update was hit. If your website runs WordPress, check today that it is on 7.1.4 or the newest release for its version, or ask whoever runs it to confirm. If your site updates itself, confirm the update actually happened. Then check your server logs for successful requests to PHP files under wp-content/upgrade around the times core updates ran, and look for administrator accounts, plugins or PHP files you do not recognize, because CISA lists this flaw as exploited.

What happened

What WordPress released. On October 28, 2026, WordPress.org announced WordPress 7.1.4. It says "this security release features fixes for multiple issues" and that "because this is a security release, it is recommended that you update your sites immediately." It says sites that support automatic background updates will update automatically. (WordPress announcement)
A weakness in the update process itself. WordPress lists "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window." Its HelpHub page calls it a race condition during core updates. Patchstack, a WordPress security firm, explains that while an update runs, a copy of WordPress sits for a few seconds in a folder called wp-content/upgrade/. If that folder can be opened from the internet, a visitor with no account could try to reach it during that window. Patchstack says the window is tiny and that it "would not call it practical to exploit," but also says the window comes back on every update, including automatic ones. (WordPress announcement, WordPress HelpHub, Patchstack)
Which versions, and how serious. Wordfence, which assigned the CVE number, rates the flaw CVSS 8.1 (high), lists WordPress Core 4.7 through 7.1.3 as affected, and names fixed releases for every branch, from 7.1.4 and 7.0.8 down to 4.7.39. It says the attack complexity is high: an attacker needs a full-package update to be running, public web access to the temporary folder, a folder name they can predict or find, and enough time before WordPress cleans up. WordPress's own announcement and HelpHub pages give no CVSS score. Its GitHub advisory, published October 29, labels the flaw Low severity and says "No known CVE," which predates both the CVE number and CISA's listing, so follow CISA's listing for urgency, not that label. (Wordfence, WordPress announcement, WordPress HelpHub)
Attackers are trying it, says Wordfence. Wordfence says its telemetry "shows that threat actors are already actively attempting to exploit the vulnerability." It reports "more than 18,500 requests targeting" the temporary installer files in the first 21 hours after its firewall rule went live. On October 30, The Hacker News reported, quoting Wordfence, that it "has blocked 62,969 attacks targeting the vulnerability" over 24 hours. We could not find the 62,969 figure in Wordfence's own post, which gives the 21-hour figure, so we show both and attribute each. Wordfence says two of the largest sources "repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window," and others tried many folder and version name variations. These are attempts that Wordfence saw or blocked. Wordfence's post does not report any site that was taken over, and notes that "Not every request used the exact vulnerable path." (Wordfence, The Hacker News)
A second flaw that needs no account. WordPress lists "unpublished customizer changesets can be discovered by unauthenticated users." Patchstack says this could show an anonymous visitor a preview of the most recent unpublished design changes, and that the settings themselves stayed protected. (WordPress announcement, Patchstack)
The rest need a logged-in account. Most of the other fixes are stored cross-site scripting flaws, meaning someone who can save content plants code that then runs in the browser of an administrator or visitor who opens it. WordPress lists them in blocks and features including the Interactivity API, the Customizer, the Categories, Playlist and image blocks, comment pagination blocks, and the privacy data erasure requests. Patchstack says almost everything else needs an account first, usually a Contributor, a few need Author or Editor, and one needs an unusual custom role. (WordPress announcement, WordPress HelpHub, Patchstack)
Other fixes in the same release. WordPress also fixed a stored denial of service in the Interactivity API, which Patchstack says hangs the visitor's browser tab, not the server, and a permissions problem with editor notes. It also updated the root certificates built into WordPress because of the eMudhra revocation; see our eMudhra notice. (WordPress announcement, Patchstack)
Exploited, per CISA. On November 3, 2026, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog as "WordPress Core Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability," saying it did so "based on evidence of active exploitation." CISA's own catalog file, which we read directly on November 3, shows the date added as November 3, 2026, a due date of November 6, 2026, and "Unknown" for known ransomware campaign use. The due date applies to US federal civilian agencies under CISA's directive BOD 26-04, which also expects them to check whether a system was compromised before it was patched. CISA does not publish its evidence or say who was hit, we found no public report naming a site that was taken over, and a listing does not mean every site that ran the old updater was hit. The assessment CISA added to the NVD record on November 3 lists exploitation as "active." Patchstack's October 28 comment that the flaw was not practical to exploit came before CISA's listing. (CISA alert, CISA KEV, NVD, Patchstack)
The flaw now has a CVE number. The CVE record for CVE-2026-119977 was published on October 31, 2026 by Wordfence, which assigned it. It describes unauthenticated remote code execution through a race condition during full-package core updates (CWE-367), and lists WordPress Core 4.7 through 7.1.3 as affected, branch by branch (for example 7.0.0 to 7.0.7 and 6.9.0 to 6.9.10). That matches the range this page already gave, and the fixed releases, from 7.1.4 and 7.0.8 down to 4.7.39. The WordPress GitHub advisory lists the same branches and fixed releases. NVD shows only Wordfence's score. (CVE record, WordPress GitHub advisory, NVD)
Older versions got fixes too. WordPress says the security fixes were backported to every branch that is still eligible, "currently through 4.7," and that only the most recent version is actively supported. Its announcement says the backports "are in progress and will ship as they become ready," but WordPress's WordPress releases page and HelpHub page already list them as released on October 28: for example 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18 and down to 4.7.39. WordPress says versions 4.6 and earlier no longer receive security updates. (WordPress announcement, WordPress HelpHub, WordPress releases page, Patchstack)

Who should worry

This is about websites built on the WordPress software you install yourself. If you are not sure whether your site runs WordPress, ask your web developer or hosting company. Ask about this if any of these are true:

Your site runs WordPress and automatic updates are turned off, or you are not sure they are on. Attackers are now trying to catch sites in the middle of a core update.
An agency, developer or host looks after your WordPress site and you have not heard whether they installed 7.1.4.
Your site ran a WordPress core update while it was on 7.1.3 or older, including the update that installed 7.1.4, and nobody has looked at the server logs for that time.
Other people have accounts on your site, such as writers, contributors, authors, editors or former staff. Most of the fixes matter most when someone with a low-level account is untrustworthy or their login is stolen.
Your site runs an older WordPress version, such as 6.x or 5.x, and has not had its latest security update.
You run a web agency or host and look after WordPress sites for clients.

This does not replace updating PHP. WordPress 7.1.4 does not change the PHP version on your server. See our PHP notice.

What to do now

Do these today.

Ask the question. Send the message below to your developer, agency or host. You need a clear answer: what WordPress version does our site run, and is it on the latest security release?
Update WordPress. In your WordPress dashboard, open Dashboard, then Updates, and install WordPress 7.1.4 if it is offered. WordPress says the update can also be downloaded from WordPress.org. Take a backup first. (WordPress announcement)
If your site updates itself, check that it did. The Updates screen shows the version you are on. If it still shows an older version, update by hand and ask your host or developer why the automatic update did not run. (WordPress announcement)
On an older WordPress version? Install the newest release for your version from the list above, such as 6.8.12 or 6.7.11, and plan the move to the current version, because WordPress says only the most recent version is actively supported. If your site is on 4.6 or older, WordPress no longer issues security updates for it, so it needs a full upgrade. (WordPress announcement, WordPress HelpHub)
Check for a break-in, even if you are now on 7.1.4. Updating closes the hole but does not tell you whether someone got in during an earlier update, and CISA lists this flaw as exploited. Ask your developer or host to look in the web server logs for successful requests (status 200) to PHP files under wp-content/upgrade around the times core updates ran, including the update that installed 7.1.4 and earlier ones. HOL Guard reads requests that were refused or not found (403 or 404) as probing, not a takeover. Cyber-Threat.net says your own updates can also cause short bursts of requests there, so compare any hit with when your updates really ran and who started them. HOL Guard says the modified time of wp-includes/version.php shows when the latest core update ran, and that the update that installed a fix was itself run by the older, unfixed updater; we have not confirmed that second point, but Patchstack says the window comes back on every update, including automatic ones. Also look for PHP files left in the wp-content/upgrade folder, for administrator accounts you do not recognize, and for plugins you did not install. If your logs do not reach back far enough, check the site itself for these signs. HOL Guard also suggests checking whether wp-config.php was changed when you did not change it. Ask for a malware scan after updating. If you find something, treat the site as compromised: restore from a clean backup, update everything and change all passwords. (CISA alert, Wordfence, Cyber-Threat.net, HOL Guard, The Hacker News)
Optional: block web access to wp-content/upgrade/ in the web server. Ask your developer or host to deny web requests to wp-content/upgrade/ in the nginx or Apache configuration, not in a plugin, and to check that the folder cannot be browsed. Wordfence says that folder is web-accessible on many servers, which is what the attack relies on, and Patchstack says a PHP security plugin cannot stop the update-process flaw, so this has to be done in the web server. HOL Guard gives the same advice. It protects future updates and is worth doing if you cannot update right away, but it is a stopgap, not a fix, and it does not tell you whether you were hit before. (Wordfence, Patchstack, HOL Guard)
If you use the Wordfence plugin, Wordfence says paying customers (Premium, Care and Response) got its firewall rule on October 28 and free users get it on November 27, that sites should confirm the firewall is optimized with its Extended Protection setting because the attack requests a PHP file directly, and that receiving the rule "does not replace installing the security update." (Wordfence)
Review who has an account. Remove accounts that are no longer needed and check that people with Contributor, Author or Editor access should still have it. Patchstack points to Contributor accounts as where most of these fixes start. (Patchstack)
Check your site afterwards. Load your main pages, test your forms and, if you sell online, place a test order.

What to send your developer, agency or host

WordPress released 7.1.4 on October 28, 2026, a security release that fixes, among other things, a weakness in the WordPress upgrade process that can lead to remote code execution during the upgrade window (CVE-2026-119977, which CISA added to its Known Exploited Vulnerabilities catalog on November 3, 2026 based on evidence of active exploitation), and a set of stored cross-site scripting flaws that need a logged-in account. WordPress recommends updating immediately. Please tell us which WordPress version our site runs, and whether it is on 7.1.4 (or the newest release for its branch). If automatic updates are on, please confirm the update actually installed. Wordfence reported attack attempts on October 29, so please check our server logs for successful requests (status 200) to PHP files under wp-content/upgrade around the times core updates ran, including the update that installed 7.1.4 and earlier ones, and check for PHP files left in that folder and for administrator accounts, plugins or PHP files we do not recognize. If anything looks wrong, please treat the site as compromised, restore a known-good backup, update everything and change all passwords, and tell us what you find. Please also check that web access to wp-content/upgrade/ is blocked in the nginx or Apache configuration (not in a plugin) and that the folder is not listable, and tell us who has Contributor, Author, Editor or Administrator accounts so we can remove any we do not need. If we are on 4.6 or older, please tell us the plan to upgrade. Sources: WordPress announcement, WordPress HelpHub, Patchstack, Wordfence, CISA KEV.

Common questions

Has my site been hacked?

This notice does not mean your site has been hacked. It means a security update is out and CISA lists the update-process flaw as exploited. CISA does not say who was hit, and we found no public report naming a site that was taken over. Wordfence reported attempts, and says the attack needs a full-package core update to be running. The way to know is to update and check the signs listed above, including the server logs for the times your core updates ran. (CISA alert, Wordfence)

Is this flaw being exploited?

CISA says so. It added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026 "based on evidence of active exploitation," with a November 6 due date for US federal agencies and "Unknown" for ransomware use. CISA does not publish its evidence. Wordfence reported more than 18,500 attempts in the first 21 hours after its firewall rule went live. We found no public report naming a site that was taken over. (CISA alert, CISA KEV, Wordfence)

Can EverThread tell me if I am affected?

No. EverThread does not test for these flaws. We check your home page from the outside, the way a browser sees it. We cannot reliably see which WordPress version a site runs, because many sites hide it. We also cannot see who has accounts on your site or whether an update has been installed. If our scan does not warn you about WordPress, that does not mean you are up to date. Our free scan does look at your home page for other common problems, such as an expired padlock certificate, missing browser safety settings and files that should not be public.

Does this flaw have a CVE number?

Yes. It is CVE-2026-119977, published on October 31, 2026 by Wordfence, rated CVSS 8.1 (high) by Wordfence. When we first wrote this notice, on October 30, there was no CVE record. WordPress's own GitHub advisory, published October 29, labels the flaw Low severity and says "No known CVE." (CVE record, WordPress GitHub advisory, Wordfence)

How many flaws did this fix?

The WordPress announcement lists twelve items and does not give a total. WordPress's HelpHub page for the release counts 22 vulnerabilities across the branches it fixed, with older branches affected by fewer, and Patchstack groups the same fixes into 17 advisories. The numbers differ because one listed item can cover several flaws and because each group counts differently, so we do not rely on one number. (WordPress announcement, WordPress HelpHub, Patchstack)

My site updates itself. Do I need to do anything?

WordPress says sites that support automatic background updates will update on their own. Confirm it: open Dashboard, then Updates, and check the version. Automatic updates can be turned off or blocked, and they can fail. (WordPress announcement)

Is this the same as the PHP flaws?

No. The PHP flaws are in the PHP language your server runs, and WordPress sites run on PHP too. Those need a PHP update from your host or developer. See our PHP notice. This notice is about WordPress itself.

Where can I follow official updates?

The WordPress announcement and the WordPress HelpHub page for 7.1.4 are WordPress's own account. Patchstack has a longer technical explanation, and Wordfence has the report of attacks.

Security alerts by email

Hear about the next one first.

When a flaw puts websites at risk, we send one plain-English email: what happened, who it affects and what to do. It's free, whether or not you use EverThread.

Sources

WordPress.org news: WordPress 7.1.4, Aaron Jorbin, October 28, 2026, checked October 30, 2026
WordPress HelpHub: Version 7.1.4, October 28, 2026, checked October 30, 2026
WordPress.org: Releases archive, checked October 30, 2026
Patchstack: WordPress 7.1.4 Security Release, Dave Jong, October 28, 2026, checked October 30, 2026
Wordfence: WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release, Wordfence, October 29, 2026, checked October 30, 2026, and again November 3, 2026
The Hacker News: WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours, Ravie Lakshmanan, October 30, 2026
CISA: Known Exploited Vulnerabilities Catalog, catalog version dated November 3, 2026, which lists CVE-2026-119977 (added November 3, 2026, due November 6, 2026, ransomware use Unknown), read from CISA's own catalog file November 3, 2026. The October 30 version had no entry.
CISA: CISA Adds One Known Exploited Vulnerability to Catalog, November 3, 2026, checked November 3, 2026
CVE Program: CVE-2026-119977, published October 31, 2026 by Wordfence, checked November 3, 2026
NVD: CVE-2026-119977, checked November 3, 2026
WordPress on GitHub: GHSA-4w3m-c66w-69mg, A race condition during core updates that could lead to remote code execution, published October 29, 2026, checked November 3, 2026
HOL Guard: WordPress update hijack bug is now on CISA's exploited list: check your last update (CVE-2026-119977), November 3, 2026, checked November 3, 2026. A security vendor's blog; used only for log-check and server-configuration guidance.
Cyber-Threat.net: Hunt for PHP requests under wp-content/upgrade, October 31, 2026, checked November 3, 2026. A security vendor's blog; used only for log-check guidance.