Update, 31 October 2026. This article first appeared on 29 October. Wordfence’s vulnerability record, updated on 30 October, now assigns CVE-2026-119977 to the core upgrade weakness, and Wordfence’s 29 October report describes repeated probing and exploitation attempts after the release. We have removed our earlier statement that exploitation status was unknown, set out the conditions an attacker needs, and added provider checks on logs and the upgrade staging directory.

Ask your provider to confirm that every production WordPress site you own runs the applicable security release and that the update actually finished. WordPress published 7.1.4 on 28 October 2026 as a security release and recommends updating immediately. As of 31 October 2026, 7.1.4 is the current release for sites on the 7.1 branch. The version documentation covers the upgrade race condition alongside other fixes.

What is now known about CVE-2026-119977

The Wordfence vulnerability record, published 28 October and updated 30 October, now identifies the issue as CVE-2026-119977. The conditions matter, and all of them must hold at the same time. According to Wordfence, an unauthenticated attacker needs a complete core update package to be unpacking its installer into a staging path beneath wp-content/upgrade. That staging tree must be both reachable from the public web and able to execute PHP. A path that is publicly visible but cannot run PHP does not complete the chain on its own. The attacker also has to predict or discover the exact path, and reach it before cleanup removes the files. In Wordfence’s testing, that window normally lasts seconds. Because every condition must line up, not every site, visitor or update is exploitable.

That narrow window has not stopped people from trying. Wordfence’s 29 October report describes repeated polling and exploitation attempts after the release. Treat that as a reason to act, not as proof that attempts succeeded. A request aimed at the upgrade directory in your logs shows that someone tried. On its own it proves neither a breach nor a clean site.

Firewall rules are an extra layer, not the patch

Wordfence released a firewall rule on 28 October. Wordfence Premium, Care and Response customers received it that same day. Wordfence Free users receive it on 27 November 2026. Because the attack sends requests directly to PHP files and bypasses the normal WordPress load, the rule only helps where the firewall runs in Extended Protection mode at the web server. Do not assume that activating a security plugin alone covers this. Any rule is an additional control. The fix is the update.

If your site is on an older branch

Wordfence lists corresponding fixes back through the 4.7 branch, but each branch has its own release. Do not treat every version from 4.7 to 7.1.3 as identical. Ask your provider to check the exact record for your branch, and plan a move to the current release, since only the latest release is actively supported and older backports are a courtesy.

  1. Inventory every install. List each production WordPress site, including forgotten microsites and landing pages.
  2. Confirm a current backup first. You want a recent files and database backup and a restore path someone has actually used. Our backup strategy guide describes what that looks like.
  3. Consider shielding the staging path, without delaying the update. A provider with server authority can consider denying public HTTP access to the upgrade staging location before running the update. Removing either the public access or the PHP execution breaks the chain described above. The Wordfence author agreed in a 30 October reply that this suits skilled operators, while warning not to postpone patching over configuration complexity.
  4. Update from the official path and verify. Follow the official update guide. A notification email or green dashboard is a prompt to check, not proof. Confirm the running version reads 7.1.4, or the correct release for an older branch.
  5. Preserve logs and look for signs of attempts. Ask your provider to keep relevant web server logs and review them for PHP requests aimed at the upgrade directory, plus any unfamiliar administrator accounts, plugins or files. Attempts are not proof of compromise, and a patch is not a clean bill of health.
  6. Test what customers touch. Check login, representative pages and an authorized form submission. If you sell online, run a checkout in test mode with no real charge.
  7. Monitor afterwards. Watch error logs and uptime alerts in the hours after the update.

Core, PHP and plugins are separate layers

This release updates WordPress core only. The PHP runtime underneath has its own fixes, which our earlier article on the PHP2Shell CVEs covered. Plugins and themes are updated separately. The WordPress hardening guide frames security as layered controls, with hosting and application responsibilities kept distinct.

What to do now

Send your provider one message asking which sites run WordPress, whether each shows 7.1.4 or its branch release after a completed update, whether a tested backup existed first, and what was checked in the logs afterwards. If you would like to discuss a documented maintenance scope, start with our WordPress maintenance service page.

Security information checked: 31 October 2026.