I’M UNDER A CYBER ATTACK

Alert

Alert 2026-138 Active exploitation of critical WordPress Core flaw during updates

Affected product(s):

ProductAffected versions
WordPress 7.17.1.0 to 7.1.3
WordPress 7.07.0.0 to 7.0.7
WordPress 6.96.9.0 to 6.9.10
WordPress 6.86.8.0 to 6.8.11
WordPress 4.7 to 6.7All versions prior to the fixed version of each branch

WordPress 4.6 and earlier do not receive a fix because they are out of support.

Description

A vulnerability has been disclosed in WordPress Core that allows a remote unauthenticated attacker to execute PHP code on the server during a core upgrade. The vulnerability has been tagged as CVE-2026-119977 (CVSSv3.1 8.1 – HIGH) and is of the time-of-check to time-of-use (TOCTOU, CWE-367) race condition type. Due to confirmed active exploitation and the widespread installed base, it is classified as CRITICAL severity.

During a core upgrade that uses the full package, affected versions extract the new files into a predictably named directory inside wp-content/upgrade/, which is published by the web server. Researchers point out that this temporary copy includes the installer (wp-admin/setup-config.php), which starts without the site configuration. An attacker who wins the race against the extraction can execute PHP code with the privileges of the web process.

Researchers point out that exploitation requires a core upgrade to be performed with the full package, web access and PHP execution enabled in wp-content/upgrade/, the temporary path to be predictable or discoverable, and the attack to complete before WordPress deletes the temporary files. In the lab the window lasts only seconds, but repeated automated probing increases the chances of success, and the window recurs on every upgrade, including automatic ones. The vendor indicated that WordPress 7.1.4 and the fixed versions of earlier branches, down to 4.7, resolve the issue.

The vendor rates the flaw as low severity due to the narrow exploitation window, while the published CVSS score is 8.1. However, the vulnerability was added on Nov 3, 2026 to known exploited vulnerability catalogs, and a European government cybersecurity agency issued an advisory flagging it as actively exploited. Public sources report massive attempts and automated probing since Oct 28, 2026, with no public details of successful compromises. No public proof of concept or association with ransomware campaigns is known.

An application firewall implemented as a WordPress plugin does not protect against this vulnerability, because the extracted copy loads WordPress from its own files and the site’s plugins do not run in that request.

Mitigation

Before upgrading, it is recommended to:

  • Deny web access to wp-content/upgrade/ on the web server, WAF, or CDN, and verify that the directory is not listable. WordPress writes to that folder via the file system and not over HTTP, so blocking it does not affect updates.
  • Place the rule in the server or virtual host configuration, or in the site’s root .htaccess, never inside wp-content/upgrade/, since vulnerable versions delete the contents of that folder before each extraction. Adjust the path if WordPress is installed in a subdirectory.
  • Do not rely solely on a PHP application firewall (plugin).
  • Verify that the block works: curl -s -o /dev/null -w '%{http_code}' https://sitio/wp-content/upgrade/ should return 403.

After upgrading, review the sites that have run any core upgrade without the patch since Oct 28, 2026, using the patterns in the detection section.

Detection

The vendor and researchers did not publish network indicators; detection is behavior-based. It is recommended to review the access logs of the web server, WAF, or CDN, since security plugins may not log these requests. Patterns to look for:

  • HTTP requests to PHP files under /wp-content/upgrade/, especially to paths ending in wp-admin/setup-config.php or wp-admin/install.php, particularly with a 200 response and at times when a core upgrade was performed.
  • Repeated, high-frequency probing of /wp-content/upgrade/ from the same IP addresses, with variations in folder or version names.
  • PHP files in wp-content/upgrade/ other than index.php outside of an upgrade.
  • wp-config.php modified without any changes of your own, or with DB_HOST, DB_NAME, or DB_USER pointing to an unknown database. In that case, the site must be treated as compromised.
  • Unknown administrator accounts, unexpected plugins, or PHP files that no one placed there, including wp-content/uploads/.

Verification commands (adjust the paths to your environment):

  • find wp-content/upgrade -type f -name '*.php' ! -path 'wp-content/upgrade/index.php' -ls
  • grep -E "/wp-content/upgrade/.*(setup-config|install)\.php" /var/log/nginx/access.log*
  • stat wp-config.php and review of the DB_HOST, DB_NAME, and DB_USER values.

Solution

The solution consists of first blocking access to wp-content/upgrade/ and then upgrading to WordPress 7.1.4 or to the fixed version of each branch, which are already available and are distributed via automatic update:

  • 7.1: 7.1.4, 7.0: 7.0.8, 6.9: 6.9.11, 6.8: 6.8.12, 6.7: 6.7.11, 6.6: 6.6.11, 6.5: 6.5.14, 6.4: 6.4.14, 6.3: 6.3.14, 6.2: 6.2.15, 6.1: 6.1.16, 6.0: 6.0.18, 5.9: 5.9.20.
  • 5.8: 5.8.19, 5.7: 5.7.21, 5.6: 5.6.23, 5.5: 5.5.24, 5.4: 5.4.25, 5.3: 5.3.27, 5.2: 5.2.30, 5.1: 5.1.28, 5.0: 5.0.31, 4.9: 4.9.35, 4.8: 4.8.34, 4.7: 4.7.39.

The update can be performed from Desktop > Updates > “Update now” or with the official download. On sites with automatic updates running in the background, the process starts automatically and installs the fixed version of their branch; even so, it is recommended to confirm the installed version on each site.

Sites on WordPress 4.6 or earlier should migrate to a supported branch.

For information on how to update, visit the following link:

https://wordpress.org/news/2026/10/wordpress-7-1-4/

Additional information: