WordPress: code execution during the core upgrade window
A race condition during WordPress core upgrades allows unauthenticated remote code execution. Secure the upgrade window and patch to 7.1.4.
Who is affected
- WordPress core 4.7.0 through 7.1.3 during full-package upgrades from the dashboard
- Hotel microsites, booking pages and property websites updated in batch across multiple domains
- Agencies and IT teams running WordPress fleets without upstream WAF coverage
How to fix
Update to WordPress 7.1.4 (or 7.0.8, 6.9.11 depending on branch, backported through the 4.7 line). Before each full-package upgrade, block web access to the wp-content/upgrade directory (WAF rule or server rewrite) and run the update from the command line rather than the dashboard. Enable automatic security updates. Confirm with your host or WAF that firewall rules execute before the site's PHP.
What happened
WordPress fixed a race condition in its full-package core update process on October 28, with version 7.1.4. Until the new release is fully installed, WordPress 4.7.0 through 7.1.3 unpack files into a predictable, web-accessible directory under wp-content/upgrade, and that staged copy includes the installer. An unauthenticated attacker polling that path during the brief deployment window can interact with the staged installer and reach code execution with the web-server process's privileges. Wordfence, the CVE Numbering Authority for this record, published CVE-2026-119977 on October 31 and scores it 8.1 under CVSS 3.1, with high attack complexity since exploitation is only possible during an upgrade. Automated probing began within hours of the patch and continues; no confirmed compromise has been documented so far. Bhutan's national CERT published operational guidance on November 2 recommending that web access to the staging directory be blocked before any upgrade.
Why it matters for a hotel
The risk does not trigger on an outdated site or an up-to-date one: it triggers at the moment you run the update. Hotel portfolios match the exposed profile exactly: dozens of microsites managed from one office, updated in batches, often during business hours, on shared hosting where wp-content/upgrade stays web-served. An actor watching a group's domains can simply wait for the window.
Who is affected
- WordPress core 4.7.0 through 7.1.3, any language, until the fixed release for the branch is installed.
- Sites updated through the dashboard (full package), where staging lands under wp-content/upgrade.
- Fleets managed by agencies: the upgrade window repeats site after site, multiplying opportunities.
How to fix
- Update every site to 7.1.4, or to its branch's security release (7.0.8, 6.9.11, backported through the 4.7 line).
- Before upgrading, block web access to wp-content/upgrade via WAF rule or server rewrite; unblock only if the upgrade fails and must be replayed.
- Prefer command-line updates (wp core update) where possible: they shorten the window and let you script the blocking rule.
- Enable automatic security updates, and schedule major upgrades off-peak, property by property rather than in simultaneous batches exposed to the same probes.
- Confirm with your host or WAF vendor that protection rules run before the site's PHP.
Context
Core WordPress this week, Gravity Forms the week before: the hotel microsite web pipeline keeps taking fixes at pace, and this flaw is unusual in that it punishes the administrator for doing exactly what they are told. The answer is not to defer updates but to secure the window: block the staging path, upgrade off-hours, verify afterward.