WordPress Vulnerability 2026: Is 7.1.3 Vulnerable? The Exploited Upgrade Flaw and How to Update Safely

Last updated: November 9, 2026. By Veer. Facts checked against WordPress.org’s 7.1.4 security release (October 28, 2026), WordPress’s GitHub security advisory GHSA-4w3m-c66w-69mg (October 29), the NVD record for CVE-2026-119977, CISA’s KEV catalog data (rechecked November 9), researcher Umut Bayram’s technical write-up for Picus Security (updated November 5), NHS England Digital’s cyber alert CC-4884, and reporting by The Hacker News (October 30 and November 6). This is a researched security explainer, not a lab test.

Is WordPress 7.1.3 vulnerable?

Yes. WordPress 7.1.3 and every release back to 4.7 are affected by CVE-2026-119977, and the fixed version on the current branch is WordPress 7.1.4. WordPress’s own security advisory lists affected ranges for each branch, from 7.1.0–7.1.3 down to 4.7.0–4.7.38, and a patched release for each one.

WordPress.org published WordPress 7.1.4 on October 28, 2026, calling it a security release and saying “it is recommended that you update your sites immediately.” On November 9, WordPress.org’s own update service was still offering 7.1.4 as the current version, so there is no newer 7.1.x release to wait for.

If your dashboard shows 7.1.3, 7.1.2 or anything older, your site is running vulnerable updater code. WordPress 4.6 and earlier get no fix at all, because only branches back to 4.7 receive security backports.

What is CVE-2026-119977, in plain English?

CVE-2026-119977 is a race condition in the WordPress core updater: during a full core update, WordPress unpacks the new version into a folder with a predictable name under /wp-content/upgrade/, and an attacker who reaches the installer inside that folder in time can end up running PHP code on the server.

The NVD description puts it this way: WordPress Core “is vulnerable to Remote Code Execution in versions 4.7 through 7.1.3” because of “predictable, web-accessible staging paths used during full-package core upgrades.”

Researcher Umut Bayram of Picus Security, who found the bug, explains the chain in his write-up:

1. A full update package contains WordPress’s own installer files, including setup-config.php.
2. WordPress extracts that package to a folder like wp-content/upgrade/wordpress-7.1.4/, which the web server can usually serve.
3. The temporary installer can’t see the site’s real wp-config.php, so it acts like a fresh, unconfigured WordPress and starts setup without asking for a login.
4. Before the fix, an attacker could write a malicious wp-config.php into that temporary copy, and the updater would copy it over the live one. That pointed the site at an attacker’s database, where they could create the first admin account and upload a plugin to run code.

Bayram says the underlying updater behavior goes back to WordPress 2.7, released in 2008. On versions 4.4 through 5.8, a random suffix on the folder name hides the path unless it leaks some other way, such as in an error message. From 5.9 onward, the folder name can be predicted again from the package filename.

How serious is it, and is it being exploited?

It is being exploited: CISA added CVE-2026-119977 to its Known Exploited Vulnerabilities catalog on November 3, 2026, with a November 6 deadline for U.S. federal agencies, and attack attempts began the same day the fix shipped. The severity rating depends on who you ask.

• Wordfence, which assigned the CVE, scores it 8.1 (High) on CVSS 3.1, with “high” attack complexity because the attacker has to win a short race (NVD).
• WordPress’s own advisory rates it Low (GHSA-4w3m-c66w-69mg).
• NHS England Digital rates it Medium and says its National CSOC “assesses further exploitation as likely” (CC-4884, last edited November 4).

The attack data is what makes the low rating hard to lean on. Wordfence told The Hacker News it blocked 62,969 attacks aimed at the flaw in the first 24 hours, and that two of the busiest sources “repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window.” By November 8, a daily threat brief from ZeroHour cited over 240,000 exploit attempts. The Hacker News also reported that code described as an exploit has appeared in public GitHub repositories, though whether it works has not been established.

In lab conditions the window lasted only seconds, per Wordfence. That’s why attackers keep polling: they don’t need to break in, they just need to be knocking when your site updates.

Which WordPress versions are fixed?

Update to WordPress 7.1.4. If you have to stay on an older branch, install that branch’s patched release from the table below. These come straight from WordPress’s security advisory; the same ranges appear in the NVD record.

WordPress only actively supports the newest version, so older-branch fixes are a courtesy. If you’re on 7.0 or 6.x, use the branch fix as a stopgap and plan the jump to 7.1.4.

Why can installing the fix expose your site one more time?

Because a WordPress core update runs two versions’ code: the old, already-installed updater unpacks the new package, and only then does the new version’s copy step take over. So the update from 7.1.3 (or older) to 7.1.4 still extracts files into a predictable folder one last time.

Bayram’s write-up explains that WordPress 7.1.4 fixes the bug three ways: a 16-character random suffix on the staging folder, keeping an index.php in /wp-content/upgrade/ so directory listings can’t reveal the folder name, and skipping wp-config.php when copying files into place. Only the third fix protects the update that installs it. During that first update, an attacker can’t replace your real wp-config.php any more, but Bayram says they can still set up the temporary copy, log in to it and run PHP with the web server’s permissions before the folder is deleted.

Whether a given update exposes the installer depends on the package. The Hacker News checked WordPress.org’s update service on November 6: it offered a smaller partial package for 7.1.3 → 7.1.4 (including automatic updates), but only complete packages for moves from an older branch, such as 7.0.7 → 7.1.4. Bayram told the outlet that the deciding factor “isn’t partial versus complete. It’s whether the updater already installed on the site has been fixed.” WordPress also falls back to a complete package if your core files don’t match official checksums or if you reinstall.

None of this is a reason to postpone. Bayram’s guidance is to block the folder and update, because “only after 7.1.4 is installed do later updates use a random staging directory.”

How do I update WordPress safely?

Block web access to /wp-content/upgrade/ first, confirm it returns a 403 error, then update to 7.1.4 (or your branch fix). If you can’t change server rules, update manually outside the web root instead. Both methods come from Bayram’s write-up and The Hacker News report.

Option 1: Block the upgrade folder, then click Update Now

WordPress reads and writes /wp-content/upgrade/ directly on disk, so blocking web access to it doesn’t break updates, Bayram says.

1. Nginx: add location ^~ /wp-content/upgrade/ { deny all; } to your server block.
2. Apache (virtual host access): add a <Directory> block for that folder containing Require all denied.
3. Only .htaccess access (common on shared hosting): add RedirectMatch 403 ^/wp-content/upgrade/ to the .htaccess file in your WordPress root, above the WordPress rewrite rules.
4. Don’t put an .htaccess file inside /wp-content/upgrade/ itself. The old updater wipes that folder before unpacking, so the file would be gone when you need it.
5. Visit https://yoursite.com/wp-content/upgrade/ in a browser or with curl -I. You want 403 Forbidden.
6. Back up, then go to Dashboard > Updates and update to 7.1.4.

Option 2: Update manually outside the web root

Back up your files and database, download and unzip the release into a folder the web server doesn’t serve, copy the core files into place without touching wp-config.php or wp-content, then run the database update (visit /wp-admin/upgrade.php or run wp core update-db). No temporary installer is ever created where the web can reach it.

WP-CLI’s wp core update is not a safe substitute. According to Bayram, it uses the same core updater and unpacks into the same /wp-content/upgrade/ folder.

If you’re on managed hosting

If your host runs updates for you and you can’t edit server config, ask support two things: whether your site is already on 7.1.4 (or a branch fix), and whether /wp-content/upgrade/ is blocked from the web. The NHS alert also tells organizations using automatic background updates to “confirm that the update has completed successfully” rather than assume it did.

What if my site auto-updated already?

If your site is already on 7.1.4 or a patched branch release, future updates are protected, but you should still check for signs that an attacker caught the one exposed update. WordPress says sites with automatic background updates should have started updating on their own when 7.1.4 shipped.

Wordfence’s checklist, as reported by The Hacker News, is to look for:

• Unexpected requests to PHP files under /wp-content/upgrade/ in your access logs (attackers often request setup-config.php there)
• Administrator accounts nobody recognizes
• Plugins nobody installed
• PHP files in /wp-content/upgrade/ that nobody put there

If you find any of these, treat the site as compromised: restore from a clean backup taken before the update, rotate admin and database passwords, and get your host involved. CISA’s KEV entry also marks the flaw for its forensic triage requirements, so U.S. federal agencies have to look for signs of compromise, not just patch.

Is CVE-2026-119977 the only WordPress vulnerability in 2026?

No. It is the third time in 2026 that CISA has listed a WordPress core flaw as actively exploited, and all three needed only a core update to fix. Here are the WordPress core entries in CISA’s KEV catalog for 2026, as of November 9.

The practical lesson is the same each time: keep core auto-updates on, and check that they actually happened. WordPress 7.1.4 also fixed 11 other security issues, mostly stored cross-site scripting (XSS) bugs, two of which WordPress credits to Anthropic, plus an update to bundled root certificates after the eMudhra revocation.

How was the flaw found, and what does AI have to do with it?

Bayram says he found CVE-2026-119977 in about four hours using OpenAI’s GPT-5.6 Sol as a research partner, a bug that had sat in the updater since 2008. In his write-up he writes: “If an early-career researcher can find a two-decade-old RCE in an afternoon, so can an attacker.”

That fits a wider pattern this autumn. The PHP2Shell bugs we covered in our PHP vulnerability explainer were also found with help from frontier AI models. If you run WordPress sites with AI tools connected (for example through Claude and MCP or one of the AI plugins for WordPress), patch core first. Those integrations don’t change this bug, but a compromised site gives an attacker everything those tools can reach.

WordPress CVE-2026-119977 timeline

FAQ

Is WordPress 7.1.3 safe to use?

No. WordPress 7.1.3 is affected by CVE-2026-119977, an actively exploited remote code execution flaw in the core updater. Update to WordPress 7.1.4, ideally after blocking web access to /wp-content/upgrade/.

What is the latest WordPress version right now?

WordPress 7.1.4, released October 28, 2026, is the current version offered by WordPress.org’s update service as of November 9, 2026. WordPress 7.2 is planned for December 8, 2026.

Can my site be hacked if I’m not updating right now?

Not through this specific flaw. CVE-2026-119977 can only be exploited during the short window while a core update is unpacking files. But every future update on a vulnerable version opens that window again, which is why you should move to 7.1.4 now.

Do I need to update if auto-updates are on?

Check, don’t assume. Sites with automatic background updates should have started updating to 7.1.4 or their branch fix on their own. Confirm the version under Dashboard > Updates, then look for unknown admin accounts or PHP files in /wp-content/upgrade/.

Is it safe to click Update Now?

Mostly, and updating is still better than waiting. The update that installs the fix runs the old updater one last time, so block /wp-content/upgrade/ from the web first (and confirm a 403 response) or update manually outside the web root.

Does WP-CLI avoid the problem?

No. Researcher Umut Bayram says wp core update uses the same core updater and unpacks into the same /wp-content/upgrade/ folder, so it carries the same one-time exposure.

Which old WordPress versions will never be fixed?

WordPress 4.6 and earlier. WordPress backported the fix to every branch from 4.7 onward, but sites older than that should move to a supported version.

Sources

• WordPress.org: WordPress 7.1.4 (October 28, 2026) and Releases archive
• WordPress on GitHub: GHSA-4w3m-c66w-69mg (October 29, 2026) and GHSA-7hp8-65ch-5whp (September 22, 2026)
• NIST NVD: CVE-2026-119977
• CISA: Known Exploited Vulnerabilities catalog (data rechecked November 9, 2026)
• Umut Bayram, Picus Security: CVE-2026-119977: When Updating WordPress Becomes the Vulnerability (updated November 5, 2026)
• NHS England Digital: Cyber alert CC-4884 (October 30, 2026; edited November 4)
• The Hacker News: WordPress RCE flaw draws nearly 63,000 attack attempts (October 30) and Installing the fix can expose some sites one last time (November 6)
• WordPress.org: WordPress 7.0.2 release (July 17, 2026)
• ZeroHour: Daily cybersecurity brief, November 8, 2026
• Related TrustLoud explainers: PHP vulnerability (PHP2Shell), how to connect Claude to WordPress with MCP, best AI plugins for WordPress