Attackers began probing a newly patched WordPress Core weakness almost immediately after the project released version 7.1.4, with Wordfence reporting 62,969 blocked exploitation attempts during the first 24 hours. The activity targeted a race condition in the Core update process that can expose a temporary WordPress installation and, under specific conditions, allow unauthenticated remote code execution.
WordPress released version 7.1.4 on October 28, 2026, describing the issue as a weakness in the upgrade process that “could lead to remote code execution during the upgrade window.” The security release fixes 22 vulnerabilities and is recommended for immediate installation by the WordPress project. [28]
The flaw affects WordPress Core versions 4.7 through 7.1.3 when a complete package is used for an update. During that process, files were extracted into a predictable directory beneath wp-content/upgrade/. If that directory was reachable through the web server, an attacker could race the update, locate the staged files and access wp-admin/setup-config.php before cleanup completed. The attack requires no WordPress account, but depends on a narrow update window, public access to the staging path and server settings that permit PHP execution there.
Security researcher Umut Bayram reported the upgrade-process issue. Public reporting places its severity at CVSS 8.1, although the official WordPress announcement does not publish a CVE identifier or a detailed CVSS vector. No confirmed compromises or publicly attributed threat actor have been established; the nearly 63,000 events represent blocked exploitation attempts rather than verified successful takeovers.
WordPress 7.1.4 addresses the exposure by making staging-directory names less predictable, retaining an index.php guard and preventing unsafe configuration files from being promoted during the update. Administrators should upgrade immediately through the WordPress dashboard or from WordPress.org releases, verify that the running version is 7.1.4 or a vendor-provided backport, and review web-server logs for requests to temporary paths under wp-content/upgrade/. Sites that cannot update promptly should restrict web access to that directory and disable PHP execution there as a compensating control.
