What changed
On 28 October 2026 WordPress shipped 7.1.4, a security release that, among other fixes, addresses “a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window”. Wordfence, acting as the CVE Numbering Authority, published this as CVE-2026-119977 with a CVSS 3.1 score of 8.1 (high attack complexity, no authentication or user interaction). WordPress’s own GitHub advisory rates it Low.
On 3 November 2026 CISA added the CVE to the KEV catalogue on the basis of evidence of active exploitation, gave US federal agencies until 6 November to act, and marked it for forensic triage. The Centre for Cybersecurity Belgium (CCB) has issued a “patch immediately” warning describing the issue as actively exploited.
Who is affected
- WordPress Core 4.7.0 to 7.1.3, on each branch up to the fixed release.
- Fixed releases: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 and backports down to 4.7.39. WordPress said backports would ship as they became ready, so confirm your branch’s release on WordPress.org.
- Exposure depends on how the site is run. The risk exists when a site performs a full-package core update through the built-in updater while
wp-content/upgrade/is reachable over HTTP and executes PHP. - Sites built from Composer, git or container images with
DISALLOW_FILE_MODSset do not run the built-in updater, so there is no upgrade window to target, but they still need the fixed code.
What we know about exploitation
- CISA lists the CVE as known exploited; CISA does not publish the evidence behind a listing.
- Wordfence reported more than 18,500 requests for staged installer paths in the first 21 hours after its firewall rule shipped, which points to automated scanning that waits for a site to start an update.
- As of 3 November, public reporting had not described a specific confirmed site takeover. Treat the scanning as real and widespread, and the success rate as unknown.
Why the order of steps matters
A site on a vulnerable version uses its existing upgrade code to install the fix. That final update can open the same short window one last time. Block web access to the upgrade folder first, then update.
What to do now
- Inventory. List every WordPress site you own or host, including staging, marketing microsites and agency-managed sites, and record the core version and whether automatic background updates are on.
- Block the staging folder first. At the web server, reverse proxy or WAF, deny HTTP access to
wp-content/upgrade/(and do not allow PHP execution there). Keep this rule in place permanently. - Update. Move to 7.1.4 or the fixed release for your branch. Sites still on WordPress older than 4.7 have no fix and should be migrated.
- Check for past compromise. Review web server logs for requests to paths under
wp-content/upgrade/, particularly any that succeeded around the time of earlier core updates. Look for unexpected PHP files, new administrator accounts, changedwp-config.phpand unfamiliar scheduled tasks. Patching does not remove access an attacker already gained. - Harden the update process. Where practical, deploy core through your build pipeline rather than the in-dashboard updater, and run updates during monitored windows.
How PoCForge can help
Our web application assessments check for exposed working directories, PHP execution in upload and staging paths, and the hosting configuration choices that turn a short race into a real compromise. If you would like an independent review of your WordPress estate after patching, get in touch.
