WordPress CVE-2026-119977 Is Being Exploited: Update to 7.1.4 Now

If your WordPress site runs 7.1.3 or earlier, update it promptly, because CVE-2026-119977 is a High-severity (CVSS 8.1) core flaw that can let an unauthenticated attacker run code on the server during a core upgrade.

This post is for owners of WordPress sites who are not security engineers. You will learn what the flaw is in plain English, how to check your version in two minutes, how to update safely, and what to look for afterward. This flaw is being exploited right now. CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on 3 November 2026, citing evidence of active attacks, and gave US federal agencies until 6 November to patch. Wordfence reported more than 18,500 requests aimed at the staged installer path in the first 21 hours after disclosure. The technical facts below come from the NVD record and the WordPress Trac code it references.

What is CVE-2026-119977?

A CVE is just a public ID number for a known security flaw. This one affects WordPress core, the main software behind your site, not a plugin or a theme.

According to the NVD record, published on 31 October 2026, the problem is a race condition in the full core upgrade process. A race condition means two things happen at nearly the same time, and the outcome depends on who wins. The weakness is classed as CWE-367 (a check-then-use timing flaw).

Here is the plain version:

• When WordPress does a full-package core upgrade, it puts upgrade files in staging paths (temporary working locations).
• Those paths are predictable, and they can be reached from the web.
• An attacker who knows the paths and hits the right moment can run code on your server. They do not need a login.

The NVD description says this affects WordPress versions 4.7 through 7.1.3. Remote code execution (running the attacker's own commands on your server) is the worst class of bug, because it can lead to a full site takeover.

How serious is it?

The NVD lists a CVSS score of 8.1 (High). CVSS is a 0 to 10 severity scale. The vector includes "attack complexity: high", which fits the story above: the attacker has to hit a timing window. That is a real limit, but it is not a reason to wait.

Two things to keep in mind:

• The NVD record has no exploitation data. We have not verified any report of attacks, so we are not claiming that attacks are happening. If you want to check for yourself, the CISA Known Exploited Vulnerabilities catalog is the primary source.
• A fix exists and it is free. Updating takes a few minutes.

The sensible read: this is a serious flaw with a quick fix. It is not a reason to panic.

Which versions are safe?

The quickest way: put your address into our free WordPress version checker. It reads the version your site announces and tells you whether wordpress.org marks it latest, outdated or insecure. If your site hides its version, use the steps below.

The NVD description says the flaw covers 4.7 through 7.1.3. The NVD configuration entries, which list exact cut-off versions, only cover branches up to 5.4. Here is what the record supports:

In short: the NVD description covers 4.7 through 7.1.3, and its listed cut-offs are 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27 and 5.4.25. For any branch where you are unsure, the safest move is to update to the latest release shown in your dashboard. You can also see releases on the WordPress releases page. Old branches miss many other fixes too.

The code changes that fix the issue are in the WordPress Trac. The NVD references include the fixed class-wp-upgrader.php in 7.1.4 and the matching update-core.php change.

Step 1: Check your WordPress version

You have two easy ways.

In the dashboard:

1. Log in to /wp-admin.
2. Go to Dashboard > Updates. It shows your version and whether an update is waiting.

With WP-CLI (a command line tool many hosts provide), run this from your site folder:

wp core version
wp core check-update

If you cannot log in, view the page source of your site and look for a generator tag. Many sites hide it, so do not rely on it.

Step 2: Update WordPress

Before you start, take a backup (files and database). Most hosts have a one-click backup. A plugin such as UpdraftPlus also works.

Then update:

1. In the dashboard, go to Dashboard > Updates and click Update to version 7.1.4 (or the latest offered).
2. Or with WP-CLI: wp core update
3. Afterward, run wp core version again to confirm.

One honest caveat. The exposure is during the upgrade window, so update promptly and then run the checks below.

If your site is on managed hosting and the update button is missing, your host may be handling it. See the next section.

Do hosts and auto-updates handle this for you?

Sometimes. WordPress can install minor and security releases automatically, and many managed hosts also apply core updates for you. But auto-updates can be switched off by a plugin, a setting in wp-config.php, or a host policy.

Do not assume. Check your version anyway. If you are on a managed WordPress plan, ask your host (or look at their status page) whether 7.1.4, or the latest release for your branch, has been rolled out to your site.

Step 3: Look for signs of trouble

The NVD does not publish attack indicators, so this is a general health check. A clean result is reassuring. It is not a guarantee.

Check for unexpected admin users. With WP-CLI:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Or go to Users > All Users > Administrator in the dashboard. Remove any account you do not recognize, and reset passwords for the rest.

Verify core files. This compares your core files to the official ones:

wp core verify-checksums

Any "file should not exist" or "checksum does not match" line is worth a closer look.

Look for PHP files where they do not belong. Uploads should hold images and documents, not code:

find wp-content/uploads -name "*.php"

This will often list harmless index.php files. These are the "Silence is golden" placeholders WordPress uses to stop folder browsing, so do not panic if you see them. To hide them and show only unexpected files, run:

find wp-content/uploads -name "*.php" ! -name index.php

Also check that wp-content/upgrade/ is empty or nearly empty. It is a staging area and should not hold leftovers after a finished update.

Check your access logs. As a general check, search for requests to the installer script:

grep "setup-config.php" /path/to/access.log

A few hits from bots do not prove anything. Many repeated requests, or POST requests, around the time of an upgrade deserve a closer look.

Quick checklist

• [ ] Back up files and database
• [ ] Confirm your version
• [ ] Update to 7.1.4 (or the latest release shown in your dashboard if you are on an older branch)
• [ ] Confirm the new version
• [ ] Run wp core verify-checksums
• [ ] Review the administrator list
• [ ] Search uploads for unexpected .php files (excluding index.php)
• [ ] Change passwords if anything looks off

What if something looks wrong?

Stay calm and work in order. Take the site offline or into maintenance mode if you can. Keep a copy of the suspicious files and logs. Then follow our website hacked guide for cleanup steps.

If you want a fast outside view first, our free website security check does a passive look at your site with no card and no login. It will not tell you whether this specific flaw was used against you, but it flags exposed and out-of-date items from the outside. If you are unsure how exposed you are in general, is my website hackable walks through the basics.

After the update: what else to tighten

This flaw is a good reminder to keep a routine:

• Leave automatic core security updates on.
• Delete plugins and themes you do not use.
• Keep backups outside the web server.
• Add security headers as an extra layer. They do not fix this bug, but they harden your site against other common attacks.

Key takeaways

• CVE-2026-119977 is an 8.1 (High) WordPress core flaw, published in the NVD on 31 October 2026. The NVD record does not include exploitation data.
• Update to 7.1.4 if you are on the 7.1 branch. On older branches, update to the latest release shown in your dashboard.
• Check your version now. Do not assume your host or auto-updates already did it.
• After updating, verify core files, review admin users, and look for unexpected PHP files in uploads (ignoring index.php).
• Back up first, and do not panic. The timing window makes this harder to exploit, but update promptly.

Want a human to look at your site?

Updating closes this hole. It does not tell you what else is open. Our $49 Circuit audit is a one-time manual review by a real security engineer, with a written report of every issue, its severity, evidence and exact fixes. It is a focused small-site audit, not an enterprise pentest or a compliance certificate. If you would rather have the high and critical issues fixed for you, Signal covers that too.