WordPress patches unauthenticated core RCE as attackers probe within hours

WordPress released version 7.1.4 on October 28, 2026, patching CVE-2026-119977, an unauthenticated remote code execution flaw in core updates.

When WordPress runs a full-package core update, it unpacks new files into a predictable folder under wp-content/upgrade that the web server can reach. The copy that is staged includes the WordPress installer. An attacker without login credentials who reaches those staged files during the brief window can execute code on the server. A successful attack requires a full-package update, public web and PHP access to the staging tree, a discoverable path, and a seconds-long race win.

WordPress.org described the flaw as “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window,” according to the release announcement posted by Aaron Jorbin. The patch randomizes the staging directory name so it cannot be guessed, places an index guard inside the staging area, and prevents unsafe promotion of staged configuration data while the upgrade runs. Rescana said the patched folder gains 16 random characters, keeps or recreates index.php if missing, and excludes wp-config.php from copied files.

On advisory GHSA-4w3m-c66w-69mg, WordPress rated the issue low and published no CVSS score. Wordfence, acting as CVE Numbering Authority, assigned CVE-2026-119977 and gave it an 8.1 High score under CVSS 3.1. Wordfence’s CVSS vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Rescana reported Patchstack’s view that the flaw rates AC:H and is not practical to exploit.

Wordfence deployed a firewall rule for paying customers on October 28, 2026, about three hours after release, and detected the first matching request nine minutes later. Probing for the flaw by attackers started within hours of the October 28 release. Wordfence logged over 18,500 requests aimed at staged installer paths in the 21 hours after the release. The Hacker News reported 62,969 Wordfence blocks over 24 hours on October 30, 2026.

Wordfence has reported no confirmed site compromise tied to CVE-2026-119977. Other sources scanned many staging-directory and version-name variations.

Every WordPress release from 4.7.0 through 7.1.3 is affected, and WordPress backported the fix to branches from 4.7 through 7.x. For the 7.x branch, patched releases are 7.1.4 and 7.0.8. For version 6.x, patched releases include 6.9.11, 6.8.12, 6.7.11, 6.6.11, and 6.5.14. Additional 6.x patches cover 6.4.14 and 6.3.14.

The list ends with 6.2.15, 6.1.16, and 6.0.18.

Patched 5.x releases run from 5.9.20 down to 5.0.31, and patched 4.x releases are 4.9.35, 4.8.34, and 4.7.39. Versions 4.6 and earlier receive no security updates.

The 7.1.4 release contains fixes for 22 vulnerabilities altogether. Sites with automatic background updates will start updating without administrator action. Wordfence says most sites should receive the release through automatic background updates but recommends checking rather than assuming completion.

Wordfence advises administrators to confirm the update under Dashboard > Updates rather than assume it completed. Administrators should review server logs for unexpected requests to PHP files beneath wp-content/upgrade, especially around recent core updates. They should look for unfamiliar administrator accounts, unrecognized plugins, and unexpected PHP files, and scan for unexpected file changes.

Users of plugin firewalls should enable extended or early-loading mode so the firewall can inspect requests that bypass WordPress, because the malicious request goes straight to a PHP file without loading WordPress. A firewall rule does not replace installing the patch. Before updating, deny web access to wp-content/upgrade/ at the web server, ensure the directory is not listable, and put the rule in server or virtual host configuration or site-root .htaccess.

Hosts and agencies should consider preventing direct PHP execution beneath wp-content/upgrade through server configuration. Many vendors operate status pages, careers pages, documentation hubs, customer portals and marketing sites on WordPress, frequently handled by agencies outside the vendor’s patch process. Sites with automatic updates off, unsupported 4.6-or-earlier releases, or installs run by agencies outside normal patching are most likely to stay exposed.

The flaw differs from other WordPress RCE bugs because of its timing requirements. An Imagick-related flaw required an Author account or higher, while successful exploitation here requires hitting a narrow window while WordPress unpacks a complete Core update.

The temporary directory remains available for only seconds in normal lab environments. A race condition occurs when a check and a use happen at different times, and here a narrow timing window means a single request is unlikely to succeed while repeated automated polling increases attacker odds. Rescana reported that Patchstack identifies wp-admin/setup-config.php as the installer file, which can run without the live site’s configuration. Some requests missed the exact vulnerable path, yet continued polling indicates attackers had grasped the race condition.

NVD listed the CVE record as received with no analysis as of October 31, 2026, at 08:16 Cyprus time, UTC+2. CVE-2026-119977 was not in CISA’s Known Exploited Vulnerabilities catalog as of October 31, 2026. CERT-FR published advisory CERTFR-2026-AVI-1420 on October 29, 2026, for versions before 7.1.4, listing remote code execution among the risks. WordPress says Umut Bayram of Picus Security reported the flaw.

WordPress’s advisory still read “No known CVE” when Rescana wrote its report. Wordfence, not WordPress, assigned the CVE and published it on cve.org on October 31, 2026. The WordPress security advisory GHSA-4w3m-c66w-69mg was published on October 29, 2026.

WordPress and Wordfence have not published network indicators of compromise (IoCs) for this flaw, and no IoCs came from CISA, CERT-EU, or CERT-FR. Customers on Wordfence Premium, Care, and Response got the new firewall rule right away. Wordfence free users will not receive the firewall rule until November 27, 2026.

Wordfence recommends installing version 7.1.4 immediately and verifying it under Dashboard > Updates rather than relying on a firewall rule alone. Sites with automatic background updates will start updating without administrator action, but Wordfence recommends checking rather than assuming completion. The patch reaches branches back to 4.7, while releases 4.6 and earlier remain unsupported. Wordfence advises blocking web access to wp-content/upgrade at the server level until patching is complete.