Menu
Breach Value Calculator

WordPress CVE-2026-119977: Update to 7.1.4 and Check for Compromise

WordPress core flaw CVE-2026-119977 is exploited and in CISA's KEV. Which versions are fixed, how to update, and how to check a site for compromise.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Published 10 min read

AI-generated illustration: WordPress CVE-2026-119977: Update to 7.1.4 and Check for Compromise
AI-generated illustration

WordPress CVE-2026-119977 is a flaw in the core software, not a plugin, that can let an outsider run code on a site while it is being updated. It is fixed in WordPress 7.1.4, released on 28 October 2026. On 3 November 2026, CISA added it to its catalogue of flaws attackers are already using. Update every WordPress site, then check each one for signs of compromise.

Sources checked 7 November 2026.

If you run a business website on WordPress, this one is about you. Most WordPress security news is about plugins. This flaw sits in the software every WordPress site shares, and in a step every site goes through: the update itself.

This post answers three questions: am I affected, what do I do today, and how do I tell whether someone got in before I patched. Deciding which patch goes first is a wider question, and the CVSS, EPSS and KEV guide explains the three scores. What else attackers are using right now is listed under exploited vulnerabilities.

What is WordPress CVE-2026-119977?

WordPress's 7.1.4 release notes describe it as "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window." The researcher credited is Umut Bayram, listed by Wordfence as being with Picus Security.

In plain terms, this kind of flaw lets a stranger on the internet take over what your web server does. The NVD record adds two details that matter for small sites. The attacker needs no login, and the opening exists only while a full core update is in progress.

CISA calls it a "Time-of-check Time-of-use (TOCTOU) Race Condition Vulnerability." A race condition is a bug where the result depends on which of two things happens first. Here, the race is between WordPress finishing its update and an outsider reaching files that are only meant to exist for a few moments.

Wordfence, which assigned the CVE, titles its advisory "WordPress Core 4.7.0 – 7.1.3 – Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution." I won't describe how the attack works in practice. You don't need that to defend against it.

Which WordPress versions are affected?

The NVD description says WordPress core "is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3." Unless your site is already on a fixed release from the table below, assume it is affected.

WordPress fixes older branches as well as the newest one. The release notes say the fixes were backported "to all branches eligible to receive security fixes," currently through 4.7. Those backports have now shipped: Wordfence's advisory, updated 31 October, lists a patched release for every branch from 4.7.39 to 7.1.4, and the NVD record gives the same fixed versions. The most common ones:

If your site runs You are fixed from
7.1.x 7.1.4
7.0.x 7.0.8
6.9.x 6.9.11
6.8.x 6.8.12
6.7.x 6.7.11
6.6.x 6.6.11
4.7.x 4.7.39

Source: NVD configuration data for CVE-2026-119977, read 7 November 2026. The record covers every branch from 4.7 to 7.1.

One caution from the same release notes: "only the most recent version of WordPress is actively supported." A backport is a safety net, not a reason to stay on an old branch.

Is it being exploited?

Yes, according to CISA. On 3 November 2026, CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalogue "based on evidence of active exploitation."

The federal due date was 6 November, three days after the listing. That deadline binds US federal civilian agencies only. For everyone else it is a signal of how seriously CISA rates the risk.

Wordfence gives a sense of scale. On 7 November 2026, its advisory reported blocking 49,284 attacks targeting this flaw in the previous 24 hours. That counts attempts on sites Wordfence protects, not successful break-ins, and it changes daily.

Why check for compromise, not just patch?

A patch closes the door. It does nothing about anyone who already came through it.

CISA's alert makes this point directly. It says its directive for federal agencies, BOD 26-04, sets expectations for when agencies must check whether attackers got into a system before it was patched. The KEV entry's required action also points agencies to CISA's forensics triage requirements, not only to the vendor fix.

This flaw has an extra twist. The risky moment is an update, and an update is exactly what you are about to run. The sources I read don't say whether the update to 7.1.4 itself passes through the vulnerable window one last time. So when you check your logs, include the time of the update, not only the days before it.

What should a small business with a WordPress site do today?

Work through these in order, one site at a time.

  1. Find every WordPress site you own. The main site, the shop, the staging copy, the campaign microsite from three years ago. Old forgotten sites are the ones that miss updates.
  2. Check the version. In the dashboard, go to Dashboard > Updates; the page shows the version you run. If you or your developer use the command line, wp core version shows it too.
  3. Update. The release notes say: "If you have sites that support automatic background updates, the update process will begin automatically." Don't assume it worked: open Dashboard > Updates afterwards and confirm the version matches the table above.
  4. On managed hosting, ask in writing. "Which WordPress version is my site on, and when was it updated?" Keep the reply.
  5. Check for signs of compromise (list below). Do this even if the update ran automatically.
  6. If you find anything odd, take a full backup of the site as it is now (it's evidence), then get help from your host or an incident response provider before you clean up.

How do I tell if my WordPress site was hacked before I updated?

  • Administrator accounts you don't recognise. In Users, filter by Administrator.
  • Files that shouldn't be there, especially PHP files inside wp-content/uploads or wp-content/upgrade. Your host's file manager can show recently changed files.
  • A changed wp-config.php. Check its last-modified date against when you last changed settings.
  • Core files that don't match WordPress's originals. Your developer can run wp core verify-checksums, which compares your core files with the official checksums from wordpress.org.
  • Odd entries in your web server's access log for paths under /wp-content/upgrade/. Your host can supply the logs.

If anything turns up, assume the attacker could read wp-config.php, which holds your database password. Change the database password and every administrator password, and replace the secret keys in wp-config.php with new ones from WordPress's key generator. New keys sign everyone out, which is the point.

What else does WordPress 7.1.4 fix?

The same release fixes a long list of stored cross-site scripting (XSS) issues. In XSS, script hidden in content runs in a visitor's or administrator's browser. They affect block markup, the Interactivity API, the Customizer, the Categories block and more.

It also updates WordPress's bundled root certificates "due to the eMudhra revocation." WordPress ships its own list of trusted certificate authorities, which it uses when it connects out to other services. If you missed that story, my post on the eMudhra key compromise explains why browsers and software are removing those roots.

How this fits with php2shell

A week before this one, CISA added the php2shell flaws in PHP itself to its KEV catalogue on 26 October 2026. Those sit one layer below WordPress, in the language it runs on. A WordPress site needs both layers fixed: PHP from your host or server, WordPress core from WordPress. My php2shell post covers the PHP side and how to prove it is patched.

Going deeper: for security and IT teams

Identifiers and scoring. CVE-2026-119977 is classed CWE-367, Time-of-check Time-of-use Race Condition. Wordfence, as the CNA, scores it CVSS v3.1 8.1 High with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Read that as: reachable over the network, no privileges, no user interaction, full impact on confidentiality, integrity and availability, but high attack complexity. The complexity reflects timing: the attacker must act inside the update window. The NVD record was published 31 October 2026 and last modified 4 November with the KEV dates (added 3 November, due 6 November). As of 7 November it carries only the CNA score.

Mechanism. CWE-367 describes code that checks a resource's state and then uses it, while something else can change the state between the two. In this case, per the NVD description, the weak point is predictable, web-reachable staging paths used during full-package core upgrades. During a full-package update, WordPress downloads the new release, unpacks it into a working directory under wp-content/upgrade, and then copies files into place. The NVD references point at the code involved in 7.1.3: wp-admin/includes/class-wp-upgrader.php, class-core-upgrader.php, update-core.php and the installer's configuration script, wp-admin/setup-config.php. The function to read is WP_Upgrader::unpack_package(), which unpacks the download into a working directory under wp-content/upgrade/. In the 7.1.4 tag it names that directory through a helper, get_working_dir_name(), documented as building "an unpredictable name for the directory a package is unpacked into", with a random 16-character suffix. Compare it with the same function in the 7.1.3 tag if you maintain a fork or a custom update process.

Threat model. The attacker is unauthenticated and remote, and needs a site that is mid-update with the staging directory reachable over HTTP. A successful attack gives code execution as the web server user. In practice that means wp-config.php, the database credentials in it, and anything else that user can write. Per the NVD description, the window opens during full-package core upgrades, so a vulnerable site is exposed each time it runs one.

Controls. - Update to the fixed release for your branch (table above) and confirm it from wp core version or the dashboard, not from the host's general announcement. - In my judgement, nothing in a normal update needs a browser to request a PHP file under wp-content/upgrade directly, because WordPress runs the update itself, from wp-admin or its background update process. Denying PHP execution there at the web server is a reasonable hardening step. In nginx that is a location block with deny all; for .php under that path. In Apache it is Require all denied for PHP files in that directory. Test on staging first, and treat it as defence in depth, not a substitute for the update. - If you use a WordPress firewall plugin, check whether it inspects requests before PHP files outside WordPress's normal entry points run. Wordfence's weekly vulnerability report for 26 October to 1 November 2026, published 5 November, lists a new firewall rule for "WordPress Core 4.7.0 – 7.1.3 – Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution", the advisory title for this flaw. It says "Wordfence Premium, Care, and Response customers received this protection immediately", while free users get it "after a 30 day delay." On the free tier, the rule arrives long after the KEV due date, so it is no reason to delay the update.

Detection and evidence. Pull web access logs from 28 October onwards, and earlier if you have them, plus the time window of each update. Search for requests to any path under /wp-content/upgrade/, especially ones ending in .php, and note the status codes. A 200 response there deserves a closer look. Then check: wp core verify-checksums for modified core files; wp user list --role=administrator for new accounts; find wp-content -name "*.php" -mtime -14 for recently changed PHP files, and any PHP file under uploads; the modification time of wp-config.php; outbound connections from the web server user; and new scheduled tasks (wp cron event list). Keep what you find. A clean result here lowers the risk; it doesn't prove nothing happened, especially if logs rotate after a few days.

Ask your host or agency: Which version is each site on, and when did it update? Do you keep access logs for at least 30 days, and will you search them for /wp-content/upgrade/ requests? Is PHP execution blocked in upload and staging directories? Which PHP version serves the site?

Key takeaways

  • CVE-2026-119977 is an unauthenticated remote-code-execution flaw in WordPress core's update process, affecting 4.7 through 7.1.3.
  • It is fixed in 7.1.4 (28 October 2026) and in backports that have shipped for every older branch back to 4.7, such as 7.0.8 and 6.9.11.
  • CISA added it to KEV on 3 November 2026 based on evidence of active exploitation; the 6 November due date binds US federal agencies only.
  • Patching doesn't remove an attacker who got in first. Check admin accounts, unexpected PHP files, wp-config.php and access logs, including the update window itself.
  • 7.1.4 also updates WordPress's bundled root certificates after the eMudhra revocation.

Sources

Spotted a mistake? Report a correction.