High priorityDisclosed

Advisory · CVE-2026-119977

Unauthenticated RCE during WordPress core upgrades

Predictable, web-accessible staging paths used during full-package WordPress core upgrades let unauthenticated attackers execute code on the server during the upgrade window.

Advisory published October 31, 2026Independent summary
Vendor
WordPress
Product
WordPress
Identifier / CWE
CVE-2026-119977
CWE-367
Action timing
Immediate
ELI5

Explain it like I’m five

When WordPress updates itself it unpacks the new version in a hallway closet whose location anyone can guess, and the door is left open. An attacker who walks in during the update can run their own code on the server.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Upgrade begins

    A site starts a full-package WordPress core upgrade, staging the new package at predictable, web-accessible paths.

  2. 02Staging path predicted

    An unauthenticated attacker works out the staging path and reaches it over the web, with no login required.

  3. 03Code executed

    The attacker executes code on the server during the upgrade window, before the upgrade finishes.

  4. 04Window closes

    The upgrade completes, but the code execution has already happened, so the attacker may already hold a foothold.

What happened

WordPress Core versions 4.7 through 7.1.3 are vulnerable to remote code execution because the full-package core upgrade process uses predictable, web-accessible staging paths. An unauthenticated attacker can execute code on the server during the upgrade window. NVD rates it CVSS 3.1 8.1 (CWE-367, time-of-check time-of-use).

WordPress 7.1.4, released October 28, 2026, is a security release that fixes a weakness in the upgrade process which can lead to remote code execution during the upgrade window, and the vendor recommends updating immediately. The vendor says the fixes were backported to all branches eligible for security fixes (currently through 4.7) and that those backports were in progress and would ship as ready, so sites on older branches should take the backported release for their branch when available rather than assuming 7.1.4 alone covers them.

What to do

  1. Update WordPress to 7.1.4, or to the backported security release for your branch when it ships.
  2. Enable automatic background updates where the site supports them, so the upgrade window is as short as possible.
  3. After upgrading, check for unexpected files, admin accounts, or code changes that could indicate the upgrade window was abused.
  4. Review web server logs covering past upgrade windows for requests to staging paths or other upgrade artefacts.
  5. Confirm the running version in the dashboard after the update and keep the site on a supported branch.

Management note

This is a core-platform flaw, not a plugin bug, so every WordPress site on an affected branch is in scope until it takes the fix. The exposure window is narrow but requires no credentials, so patching speed matters more than usual: treat the update as urgent and verify it landed.