WordPress 7.1.4, released on October 28, 2026, closes a serious unauthenticated remote code execution flaw in the Core update process, and security researchers say attackers were already trying to exploit it within hours of the patch going live. The issue is unusual because it can be triggered without a site account, but only during a very narrow upgrade window while WordPress unpacks a full Core package.
What WordPress 7.1.4 fixes
According to WordPress, the 7.1.4 release addresses 22 security vulnerabilities across WordPress Core. The most urgent is an upgrade-window race condition that can lead to remote code execution, but the release also includes fixes for stored cross-site scripting, denial of service, information disclosure, authorization weaknesses, and other issues.
The security update applies to the current branch and has also been backported to older supported branches. WordPress says the patched versions include 4.7.39, 4.8.34, 4.9.35, 5.0.31, 5.1.28, 5.2.30, 5.3.27, 5.4.25, 5.5.24, 5.6.23, 5.7.21, 5.8.19, 5.9.20, 6.0.18, 6.1.16, 6.2.15, 6.3.14, 6.4.14, 6.5.14, 6.6.11, 6.7.11, 6.8.12, 6.9.11, 7.0.8, and 7.1.4.
How the unauthenticated RCE works
The vulnerability is tracked as CVE-2026-119977 and carries a CVSS score of 8.1. Wordfence describes it as an “Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution” issue affecting WordPress Core versions 4.7.0 through 7.1.3.
The problem stems from predictable, web-accessible staging paths used during full-package Core upgrades. During the update, affected versions unpack new files into a temporary directory under wp-content/upgrade. That staged copy includes the WordPress installer, and if an attacker requests it at exactly the right moment, they may be able to interact with the installer and move toward code execution.
The catch is timing. Wordfence says the attacker has to win a race against a process that usually lasts only seconds in lab environments. That makes the exploit difficult to pull off with a single request, but repeated automated polling can increase the chances of hitting the window.
Why this is considered high risk
- No site account is required.
- The attack can lead to code execution on the server.
- Attackers can automate repeated requests to try to catch the update window.
- The vulnerable files may be exposed directly on the web in some server configurations.
Exploitation attempts were seen quickly
Wordfence says threat actors began probing for the flaw almost immediately after the release. Its telemetry recorded the first match for the new firewall rule nine minutes after deployment, and more than 18,500 requests targeting staged setup-config.php installer paths in the first 21 hours.
Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, behavior the company says is consistent with trying to catch the brief upgrade window. Other requests tested many staging-directory and version-name variations, suggesting attackers quickly adapted their scanning to the new disclosure.
Wordfence response and firewall timing
Wordfence says its Threat Response Team deployed a new blocking firewall rule on October 28, 2026, at 20:30 UTC, roughly three hours after WordPress announced the security release. Wordfence Premium, Care, and Response customers received the rule immediately. Wordfence Free users will receive the same rule on November 27, 2026, after the standard 30-day delay.
The company also warned that this exploit directly requests a staged PHP file without first loading WordPress. For that reason, it says sites using Wordfence should make sure the firewall is optimized with Extended Protection, which allows the firewall to run before direct PHP requests reach the file. Even so, Wordfence stresses that firewall protection is not a substitute for installing the patch.
What site owners should do now
Most WordPress sites should receive security updates automatically, but WordPress and Wordfence both recommend verifying the version rather than assuming the update completed. Site owners should check Dashboard > Updates and confirm they are running WordPress 7.1.4 or the corresponding security release for their branch.
Sites on WordPress 4.6 and earlier no longer receive security updates and should be upgraded to a supported release. If a site remained unpatched during the release window, administrators should also review suspicious activity in the upgrade directory and look for unexpected PHP files, unfamiliar administrator accounts, or signs of tampering.
Practical steps to take
- Verify WordPress is updated to 7.1.4 or the matching patched branch release.
- Confirm the Wordfence firewall is enabled and optimized with Extended Protection.
- Do not rely on the firewall instead of patching the site.
- Inspect wp-content/upgrade for unexpected PHP activity or file changes.
- Run a Wordfence scan after updating to check for malicious files or Core changes.
More than the headline bug
While the upgrade-window RCE is the most severe issue in the release, it is only one part of the broader fix set. WordPress 7.1.4 also addresses multiple stored XSS flaws involving block delimiters, the Categories block, Comments Pagination and Post Navigation labels, Customizer selective refresh, personal data erasure requests, specially crafted usernames, and Image and Playlist block handling.
The release additionally fixes several Interactivity API issues, including unsafe URL, event-handler, internal-property, and object bindings; prototype pollution; Script Module data shadowing; uploaded text-file handling in the Interactivity Router; and a persistent denial of service condition. WordPress also says the update resolves an unauthenticated information disclosure issue affecting unpublished Customizer changesets, an authorization weakness in the Notes REST API, and includes updated root certificates following the eMudhra revocation.
Many of those remaining bugs require an authenticated Contributor, Author, or Editor account, and some also depend on a victim viewing attacker-controlled content. That lowers the exposure compared with the unauthenticated RCE, but stored XSS and similar flaws can still be dangerous if a privileged user encounters malicious content.
For WordPress site owners, the message from this release is straightforward: patch first, then verify protections are active. The upgrade-window flaw is difficult to exploit, but active scanning began quickly, and the short race window is still enough for automated attackers to keep trying.
Source: Original report
Was this helpful?
Explore more: WordPress Troubleshooting More WordPress & CMS Tech News
Last Modified: October 30, 2026 at 10:32 pm
3 views
