Introduction

The National Cyber Coordination and Command Centre (NC4) draws attention to CVE-2026-119977, a race condition in the WordPress Core upgrade process that may allow an unauthenticated attacker to execute code on the web server while a core update is in progress. WordPress fixed the vulnerability in version 7.1.4 on 28 October 2026 and released fixes for all branches back to 4.7. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog on 3 November 2026 on the basis of evidence of active exploitation.

Security vendors have reported large volumes of automated exploitation attempts against staged upgrade paths since the fix was released. Successful compromises have not been publicly confirmed, and exploitation depends on precise timing during an update. However, the attack requires no account or user interaction, and the exposure window reopens on every core update, including automatic background updates.

Impact

During a full-package core upgrade, WordPress unpacks the new release into a folder under wp-content/upgrade/, which is served by the web server. In affected versions, the folder name is predictable and could be revealed through directory listing. Thus, a complete copy of WordPress, including its installer (wp-admin/setup-config.php), is briefly reachable over the web. An attacker who reaches the staged installer during this window can run it against a database under their control. Successful exploitation may result in:

• execution of attacker-controlled PHP code with the privileges of the web server account;
• compromise of the website, including installation of web shells, malicious plugins or unauthorised administrator accounts; and
• exposure of configuration data and database credentials, and use of the server as a foothold for further attacks.

Exposure Conditions

A site is exposed when all of the following conditions apply:

• it runs an affected WordPress Core version (4.7 to 7.1.3, or an unpatched release on an older branch);
• the wp-content/upgrade/ directory is reachable over HTTP; and
• a full-package core update runs, whether started manually, through WP-CLI or by automatic background updates.

Note: Exposure is higher where directory listing is enabled, as the staging folder name can then be read directly. WordPress security plugins that load through WordPress may not inspect requests to the staged copy, because it loads WordPress from its own files. The vulnerability is rated high attack complexity because requests must arrive within the seconds an update takes; attackers compensate by polling targets automatically.

System Affected

WordPress has released fixed versions for every branch still eligible for security updates. Only the most recent release is actively supported; fixes for older branches are provided as a courtesy, and organisations should plan to move to a current release.

Recommendation

NC4 recommends that organisations take the following actions:

A.     Block Access to the Upgrade Directory Before Updating

• Before applying the update, deny web access to wp-content/upgrade/ at the web server or reverse proxy, and disable directory listing. This does not affect updates, which WordPress performs through the local file system. Example configurations:

# Apache (virtual host, or .htaccess placed in wp-content/upgrade/)

Require all denied

Options -Indexes

# Nginx

location ^~ /wp-content/upgrade/ { deny all; }

• Keep the restriction in place after patching. Between updates the directory should contain nothing but an index.php file.
• Where an edge or reverse-proxy web application firewall (WAF) is used, confirm that it inspects and blocks requests to wp-content/upgrade/. Do not rely solely on WordPress firewall plugins, which may not run for requests to the staged copy.

B.     Patch and Verify

• Update WordPress Core to version 7.1.4 or the fixed release for your branch as listed above.
• Verify the installed version on every site, through Dashboard > Updates or, for multiple sites, with the WP-CLI command wp core version. Confirm that automatic background updates have completed, and prioritise sites where automatic updates are disabled.
• Include staging, development and cloned copies of sites, which use the same update process.
• Migrate sites running WordPress 4.6 or earlier, which no longer receive security updates.

C.     Compromise Assessment and Monitoring

• For sites that ran a core update before the access restriction and patch were in place, review web server access logs around each update time.
• Treat any request under /wp-content/upgrade/ as suspicious. The strongest indicator is a request to a staged wp-admin/setup-config.php that returned HTTP 200, particularly a POST request with step=2, which is the step where database connection details are submitted.
• Review network telemetry for outbound connections from the web server to external database hosts, which may indicate that the staged installer was pointed at an attacker-controlled database.
• Confirm that wp-config.php has not been modified at or after an update time and that DB_HOST and other settings are as expected. Run wp core verify-checksums to identify modified core files.
• Look for signs of follow-on activity: unfamiliar administrator accounts, unrecognised plugins or themes, unexpected PHP files in web directories (including wp-content/uploads/), and unexpected processes started by the web server.
• Treat these behaviours as hunting opportunities rather than standalone indicators of compromise. Where compromise is suspected, preserve logs and files before remediation, rotate database credentials and WordPress authentication keys and salts, and report the incident as described below.

Reporting

Organisations identifying attempted exploitation or confirmed compromise should report the incident through the appropriate national reporting channel.

NCII entities should continue to comply with applicable reporting obligations under the Cyber Security Act 2024 [Act 854] and associated regulations. Other organisations are encouraged to submit cybersecurity incident reports through NACSA's designated reporting channels.

Disclaimer

This advisory reflects information available to NC4 as of 5 November 2026. Exploitation activity, affected product coverage and vendor remediation guidance may change as additional information becomes available. Organisations should continue to monitor official vendor and government cybersecurity advisories for updates.

References

1. CISA - CISA Adds One Known Exploited Vulnerability to Catalog (3 November 2026)    https://www.cisa.gov/news-events/alerts/2026/11/03/cisa-adds-one-known-exploited-vulnerability-catalog

2. NVD - CVE-2026-119977    https://nvd.nist.gov/vuln/detail/CVE-2026-119977

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

4. WordPress - Version 7.1.4 (fixed releases for older branches)    https://wordpress.org/documentation/wordpress-version/version-7-1-4/