WordPress: RCE flaw in core during updates, in CISA KEV since 3 November

Wordfence reports that attacks against an RCE flaw in WordPress core began on the same day as its disclosure, 28 October 2026, peaking between 29 October and 1 November. For those managing WordPress hosting at scale, the news matters because the vulnerability affects not a third-party plugin but the core update mechanism itself.

What the bulletin says

On 28 October 2026, the WordPress Security Team released version 7.1.4, along with security backports for older branches, addressing several security issues, notably an unauthenticated Remote Code Execution vulnerability in WordPress core, identified as CVE-2026-119977. The flaw affects core versions 4.7 through 7.1.3 and can be exploited by unauthenticated attackers to execute code on the server during a core update, resulting in complete site compromise.

Wordfence, acting as CVE Numbering Authority, assigned the flaw a CVSS 3.1 score of 8.1 (High), based on a time-of-check time-of-use (TOCTOU) race condition in the WordPress update process. WordPress.org, in its advisory, rates it as Low instead—a difference worth noting when deciding patch priority.

How it works and what changed in 7.1.4

During a full core update, WordPress temporarily extracts the new package to a web-accessible staging location under the wp-content/upgrade directory, before replacing the existing installation. The attack window is brief: it is a race condition difficult to exploit, exploitable only during the short interval whilst a core update is in progress. According to Hostingseekers' analysis, version 7.1.4 adds 16 random characters to temporary folder names, restores index.php protection, and prevents wp-config.php from being copied from the working directory.

Deadlines and recommended actions

CISA added the flaw to the KEV catalogue on 3 November 2026, with remediation deadline set to 6 November 2026 for US federal agencies. For those managing WordPress hosting, the practical priority remains updating immediately to 7.1.4 (or the patch for your branch, going back as far as 4.7) and, in the meantime, blocking HTTP access to wp-content/upgrade/ at web server level. A public proof-of-concept for the flaw is already circulating on GitHub, further narrowing the window for delaying the update.