WordPress 7.1.4: the flaw attackers exploit while your site is updating

Published on November 6, 2026 · The mitza.es team

On October 28, 2026 WordPress released version 7.1.4, a security update that fixes a weakness in the core update process itself. Six days later, on November 3, the US agency CISA added the flaw, identified as CVE-2026-119977, to its catalog of actively exploited vulnerabilities (KEV). In other words: it is no longer a theoretical risk. We summarize what is confirmed as of November 6, 2026 and what is not yet.

What happened, step by step

• October 28: WordPress.org releases 7.1.4 as a security release. The announcement describes “a weakness in the WordPress update process that can lead to remote code execution during the update window” and credits Umut Bayram, the researcher who reported it.
• November 3: CISA adds CVE-2026-119977 to the KEV catalog, “based on evidence of active exploitation”. The deadline it sets for US federal agencies is November 6.
• Before the alert: according to SOC Prime's analysis, which draws on honeypot telemetry published by The Hacker News, exploitation attempts were already recorded on October 30. These are recorded attempts, not confirmed successful attacks.

One clarification: the WordPress.org announcement does not cite the CVE number. The link between that notice and CVE-2026-119977 is established by the description of the flaw and by the researcher who reported it; CISA links version 7.1.4 in its own entry.

What exactly this flaw is

CISA classifies it as a time-of-check time-of-use race condition (TOCTOU, CWE-367) and explains that it could allow unauthenticated attackers to run code on the server during the “update window”. The cause it cites is technical but easy to grasp with an analogy:

When WordPress updates its core with a full package, it downloads the new files and leaves them ready in an intermediate area before replacing the old ones. According to CISA, those staging paths were predictable and reachable from the web. It is as if, while you change the lock on your front door, you left the box with the new keys on the doormat for a few minutes: the danger doesn't exist the rest of the year, but during those minutes anyone passing by can take advantage of it.

From what has been published, the risk is concentrated in that interval, and SOC Prime rates the attack complexity as high (CVSS 3.1 score of 8.1 according to its analysis; we have not been able to verify it in the NVD database). That is no reason to wait: the patch is available and WordPress recommends updating immediately.

Affected versions

SOC Prime states that the flaw affects WordPress from version 4.7 through 7.1.3, and that the fix has been backported to older branches that still receive security patches. WordPress.org confirms the latter: the fixes have been backported “to all branches eligible to receive security fixes (currently up to 4.7)”, but it warns that those older versions are being released as they become ready. If your site is on an older branch, check in the updates panel whether the version for your branch is already available or, after making a backup and running a test, jump to 7.1.4.

What to do today: checklist

1. Check your version. In the admin panel, go to Dashboard → Updates. If it isn't 7.1.4 (or the fix for your branch), update.
2. Make a backup before updating, without delaying the update because of it. If you don't have an orderly system, here we explain the 3-2-1 backup rule.
3. Don't assume the automatic update finished properly. WordPress.org states that, on sites with background updates, the process starts on its own. Check in the panel that the version is the right one and that there is no failed-update notice.
4. Ask your host. Some managed WordPress providers update for you. Ask them to confirm the version and date in writing.
5. Look for unusual activity if your site ran a core update in recent weeks: admin users you don't recognize, new or modified files in the root and in wp-content, changes to wp-config.php or .htaccess. According to SOC Prime, the requests observed targeted temporary installer paths (such as setup-config.php), so you can also search for those paths in your server's access logs.
6. Change credentials if in doubt (administrators, database, SFTP) and review the installed plugins: remove the ones you don't use.
7. Write down the date and the actions taken. If personal data were affected, that timeline will help you assess with your advisor whether the AEPD (Spain's data protection agency) needs to be notified.

Two honest caveats: CISA's entry says it is not known whether the flaw is used in ransomware campaigns and calls for forensic triage under its BOD 26-04 directive, aimed at US federal agencies. For an SME, the practical translation is: if your site updated its core in recent weeks with a vulnerable version, it deserves a review, not just a patch.

If you think your site is already compromised

Signs such as odd redirects, pages you didn't create, new users, Google warnings or a host that suspends the account are reasons to act in an orderly way. We have prepared a step-by-step guide: my WordPress site has been hacked: what to do, signs, cleanup and prevention. For a professional review, our website security audit checks versions, users, files and server configuration.

Why this keeps happening and how to reduce the risk

It adds to other serious WordPress alerts we have covered this autumn: the CVE-2026-87902 flaw in 7.1.2, the wp2shell family and the plugins exploited in October. WordPress powers a huge part of the internet, so it is the most profitable target. That doesn't mean it shouldn't be used; it means it can't be left without maintenance.

• Keep an update calendar for the core, plugins and theme, and a maximum window for critical patches.
• Use a testing environment (staging) to rehearse major updates before applying them in production.
• Put a web application firewall (WAF) in place: it reduces attempts, but it doesn't replace updating, because the flaw is in WordPress itself. If you want to understand the first line of defense, read what a firewall is and what a small business needs.
• Turn on two-step verification and unique passwords for all administrators.
• Delegate the maintenance if it isn't your job: you can find the breakdown of what it includes in website maintenance: what it includes and what it costs.

Quick questions

Does it affect me if my WordPress is on WordPress.com?

The notices we have reviewed talk about WordPress installations that update their own core. If your site is on a managed platform, ask your provider whether it has already applied the fix; we have not found a specific statement from WordPress.com about it.

Does deactivating plugins help?

Not for this flaw: it is in the core, not in a plugin. The effective measure is to update to the fixed version.

Should I worry if I already updated?

If your site updated its core before October 28, that update was carried out by a vulnerable version; the specific risk depends on whether someone attacked at exactly that moment. It deserves a quick review of users and files. If you updated afterwards, just check that the version is the right one.

How we can help at Mitza

We update and review WordPress as part of our website maintenance service, with backups, prior testing and a warning if something fails. If you'd rather start by finding out what state your site is in, tell us about your case on the contact page.

Related reading: the Ivanti Connect Secure zero-day and IT maintenance for small businesses.