Skip to content
Hacker Posts

WordPress core RCE CVE-2026-119977 exploited; fix is in 7.1.4

CVE-2026-119977 lets unauthenticated attackers run code during full-package WordPress core updates. CISA added it to KEV. Fixed in 7.1.4 — but the update itself opens one last window.

Published 3 min read
cvewordpressrceadvisory

A WordPress core flaw tracked as CVE-2026-119977 lets an unauthenticated attacker run code on a site during a core update, and it is being exploited. CISA has added it to the Known Exploited Vulnerabilities catalog. The fix is WordPress 7.1.4, with backports for older branches — but installing that fix can expose a site one last time. If you run WordPress, read the sequencing below before you click update.

What's affected

  • WordPress core 4.7 through 7.1.3.
  • Fixed in 7.1.4 and in matching security releases on older supported branches.

NVD describes the bug as unauthenticated RCE caused by "predictable, web-accessible staging paths used during full-package core upgrades." Wordfence, the CVE's assigning authority, scores it CVSS 8.1; WordPress's own advisory rates it low.

The flaw

During a full-package core update, WordPress unpacks the new release into a temporary folder under wp-content/upgrade/ — including the installer — then deletes it. On many servers that folder is reachable over the web. An attacker who can guess the folder name and hit the installer inside that window runs code unauthenticated. The researcher who reported it, Umut Bayram of Picus Security, traces the weakness back to WordPress 2.7 (2008).

The sting is in the fix: 7.1.4 randomizes the folder name, but the update that installs it runs the old code, which on 5.9+ sites names the folder after the downloaded file — predictable one last time. Within-branch updates (7.1.3 → 7.1.4) ship as partial packages and avoid this; cross-branch updates (e.g. 7.0.x → 7.1.4) ship as full packages and don't.

Exploitation status

Wordfence reports it saw attack attempts about nine minutes after deploying a firewall rule on release day, and BleepingComputer reports roughly 13,095 blocked attacks in 24 hours. Code described by its authors as an exploit has appeared on public GitHub repositories. Wordfence lists these compromise indicators:

  • Unexpected requests to PHP files under wp-content/upgrade/.
  • PHP files in wp-content/upgrade/ that no one placed there.
  • Unrecognized administrator accounts or unfamiliar plugins.

Action checklist

  1. Block web access to wp-content/upgrade/ before updating. On Nginx:
location ^~ /wp-content/upgrade/ { deny all; }
  1. Confirm requests to /wp-content/upgrade/ return 403, then update to 7.1.4 (or the fixed release for your branch).
  2. Prefer a within-branch update or a manual update outside the web root; note WP-CLI's wp core update is not a substitute here.
  3. After updating, remove the deny rule only if you need it gone, and review logs for requests to that path during your update window.
  4. Audit admin accounts, installed plugins and wp-content/upgrade/ for the indicators above.

Context

The pattern is a familiar one for WordPress: the dangerous surface is not a third-party plugin but the update machinery itself, and the mitigation runs counter to muscle memory — the one action every guide tells you to take, updating, is also the moment of maximum exposure. Sites on 4.6 and earlier receive no security updates at all and should move to a supported branch regardless.

Related stories