WordPress shipped version 7.1.4 on October 28, 2026, to close an unauthenticated remote code execution flaw in the way core updates itself, and attackers started probing for it within hours. The bug, tracked as CVE-2026-119977, affects every WordPress release from 4.7.0 through 7.1.3. Wordfence, which assigned the CVE, says it detected exploitation attempts shortly after the fix went public, and its vulnerability page for the flaw showed 45,055 blocked attacks over a 24-hour period as of October 31.
The weakness does not sit in a plugin or a theme. It sits in the update routine that millions of site owners trust to keep them safe, which means the moment a site begins patching itself is, in this case, the moment it can be most exposed. That irony is why administrators should treat 7.1.4 as an urgent update and then confirm it actually landed.
A patch day that turned into a race
The WordPress.org release announcement, posted by core contributor Aaron Jorbin, describes the issue as “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window.” The project credits Umut Bayram of Picus Security with reporting it.
Events moved quickly after the release:
- October 28: WordPress 7.1.4 ships with fixes backported to every branch back to 4.7.
- October 28, 4:30 PM EDT: Wordfence deploys a firewall rule for paid customers, about 3 hours after the release. The first request matching that rule arrives 9 minutes later.
- October 29, 3:12 PM EDT: The WordPress security team publishes advisory GHSA-4w3m-c66w-69mg on GitHub.
- October 29: Wordfence publishes its analysis, reporting more than 18,500 requests aimed at staged installer paths in the first 21 hours.
- October 31, 1:33 AM EDT: The CVE record goes live with a CVSS 3.1 base score of 8.1.
Wordfence says 2 large traffic sources repeatedly polled small groups of sites for roughly 14.5 hours, a pattern consistent with attackers waiting for a target to start updating rather than spraying the whole internet at once.
Where the weakness sits
When WordPress performs a core update with a full package, it unpacks the new files into a working folder before moving them into place. According to the GitHub advisory, that working folder sat at a predictable location inside wp-content/upgrade, a directory the web server can reach. For a short period, the staged files existed there in a state an outsider could request directly.
An unauthenticated attacker who reaches the staged files at the right moment can turn that brief exposure into code execution on the server. The flaw is classed as CWE-367, a time-of-check to time-of-use race condition. BreachNews is not publishing the request details or timing involved.
The fix in 7.1.4 does 3 things, according to Wordfence:
- It randomizes the name of the staging directory so it can no longer be guessed.
- It adds an index guard to the staging area.
- It blocks unsafe promotion of staged configuration data during the upgrade.
Why the ratings disagree
The two official sources do not agree on how serious the bug is. The WordPress security team labeled its GitHub advisory “low” and attached no CVSS score. Wordfence, acting as the CVE Numbering Authority, scored it 8.1 High with the vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The NVD entry still shows the record as received and has not added its own analysis.
The gap comes down to how much weight the preconditions carry. A successful attack requires all of the following:
- The site must run a core update using a complete package rather than a partial one.
- The staging tree must be publicly reachable with PHP execution enabled.
- The attacker must know or discover the staging path.
- The attacker must win a race window that, in lab testing, lasted only seconds.
BreachNews rates this story High. The bug needs no login, the impact is full code execution, and real attack traffic appeared almost immediately. We stopped short of Critical because the high attack complexity and narrow window limit how many sites can realistically be hit, and no source has confirmed a successful compromise.
What attackers have been doing since release
Wordfence describes the traffic as exploitation attempts, not confirmed breaches. Its firewall counted more than 18,500 requests against staged installer paths in the first 21 hours, and its vulnerability page later showed 45,055 blocked attacks over a rolling 24-hour period. Wordfence has not publicly reported a confirmed successful compromise tied to CVE-2026-119977.
The polling pattern matters for defenders. Because the flaw only opens during an update, attackers appear to be checking the same sites over and over, hoping to catch one mid-upgrade. Sites that update automatically on a predictable schedule, or that sit on large shared hosts where many installs update at once, could make that waiting game easier.
There is also a firewall blind spot. Wordfence notes that the malicious request goes straight to a PHP file and never loads WordPress itself, so a plugin-based firewall only sees it when it runs in Extended Protection mode. Users of the free Wordfence tier will not get the firewall rule until November 27, 2026, nearly a month after the patch.
Patched builds for 25 branches
WordPress backported the fix to every branch from 4.7 onward. According to the 7.1.4 release notes, the patched versions are:
- 7.x: 7.1.4 and 7.0.8
- 6.x: 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16 and 6.0.18
- 5.x: 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28 and 5.0.31
- 4.x: 4.9.35, 4.8.34 and 4.7.39
Versions 4.6 and earlier receive no security updates. WordPress also stresses that only the newest release is actively supported, so backports are a safety net rather than a long-term plan. The fix is already included in WordPress 7.2 Beta 3, and the final 7.2 release is planned for December 8.
The other 21 fixes in 7.1.4
The upgrade race is the headline, but 7.1.4 patches 22 vulnerabilities in total. Most of the rest are stored cross-site scripting bugs that require a Contributor-level account or higher. The release also fixes an unauthenticated information disclosure in Customizer changesets, a permissions issue in the Notes feature, a denial of service in the Interactivity API, and updates the bundled certificate store with an eMudhra root certificate.
Those lower-severity issues still matter for sites that hand out Contributor, Author or Editor accounts to freelancers, guest writers or agencies. A stolen or misused low-privilege account becomes more useful to an attacker when stored XSS bugs are available.
Checking a site after the fact
The announcement notes that sites supporting automatic background updates will begin updating on their own. Wordfence advises against assuming that worked. Administrators should take these steps:
- Open Dashboard > Updates and confirm the site reports 7.1.4 or the patched version for its branch. If not, click Update Now.
- Check the web server logs for unexpected requests to PHP files under
wp-content/upgrade, especially around the time of recent core updates. - Look for unfamiliar administrator accounts, plugins you did not install, and PHP files you did not place.
- Run a malware scan after updating.
- If you use a plugin firewall, enable its extended or early-loading mode so it can inspect requests that bypass WordPress.
- Do not treat a firewall rule as a substitute for the patch.
Hosts and agencies that manage many sites should consider whether their staging directories are reachable from the web at all. Blocking direct PHP execution under wp-content/upgrade at the server level may reduce exposure to this class of bug.
Third core scare since July
CVE-2026-119977 adds to a difficult year for WordPress core. In July, BreachNews covered the WP2Shell vulnerabilities, two core flaws that researchers said could be chained into unauthenticated remote code execution. In September, the Click2Shell flaw showed how core could be pushed into installing a theme and paired with a vulnerable one for PHP execution.
The underlying stack has been under pressure too. Last month, PHP2Shell brought 2 critical PHP bugs and reports of exploitation. Earlier in the summer, researchers exposed the infrastructure behind the WP-SHELLSTORM webshell campaign, which allegedly compromised thousands of WordPress and Joomla sites.
The pattern is consistent. Attackers watch WordPress security releases closely and move within hours, while a long tail of sites runs old branches or never confirms its updates. This time, the flaw lives inside the update process itself, so the safest window is the one after a site has finished patching and the owner has checked that it did.
