The hole is not on your site today. It appears for a few seconds while your site installs its next update — and someone is watching for it.
On October 28, 2026, WordPress shipped version 7.1.4 with fixes for 22 vulnerabilities. Twenty-one of them are the kind you have read about before: stored cross-site scripting in a block, a permission check that was too loose, an information leak. One is different in a way that matters more than its score suggests.
The flaw, tracked as CVE-2026-119977, does not live in a page, a plugin, or a login form. It lives in the update process itself. For a few seconds while WordPress unpacks a core update, affected versions create a work area that anyone on the internet can reach. An attacker who times a request into that window can run code on your server. No account, no password, no admin access.
WordPress fixed it. Then three things happened in the days that followed, and together they make this worth ten minutes of your week even if you have never opened your site's dashboard:
- Attackers started probing for it nine minutes after the first firewall rule went live.
- Wordfence logged more than 18,500 requests aimed at the staging files in the first 21 hours, with the two busiest sources polling a small set of sites for roughly 14.5 hours straight.
- On November 3, CISA added it to the Known Exploited Vulnerabilities catalog, the list of flaws confirmed to be used in real attacks. Federal agencies in the United States were given until November 6 to patch.
The score is 8.1 out of 10, rated high, not critical. That number is honest and also easy to misread. So let us do the plain-language version first.
What the flaw actually is
When WordPress installs a complete core update, it downloads the package, unpacks the new files into a temporary folder beneath wp-content/upgrade, then moves them into place and cleans up. That temporary copy is a full WordPress installation, including the setup files.
On a lot of servers that folder is reachable from a browser. So for the length of the unpack, a stranger can request the installer sitting inside it and walk through the setup process against a copy of your site.
WordPress describes the fix as three changes: the staging folder name is now randomized instead of predictable, an index guard blocks directory browsing, and the update process no longer promotes staged configuration data in an unsafe way.
Here is the part most coverage skips, and it is the part that decides whether you should care. The 8.1 score measures what happens if an attacker gets through. It does not describe the setup. To get through, someone needs all of the following at once:
- A complete-package core update in progress on your site — not a plugin update, not a theme update.
- Public web and PHP access to the staging tree. If your host blocks that path, the door is shut.
- A staging path they can predict or find.
- Enough time to complete the attack before WordPress deletes the temporary files.
Wordfence, which published the technical writeup, watched the staging directory survive for only seconds in lab environments. High attack complexity, in scoring language, is a real thing and not a formality.
But "high complexity" is only reassuring if nobody is willing to be patient. Somebody was.
Why "a few seconds" does not mean what it sounds like
A window of a few seconds sounds like protection because we imagine an attacker making one attempt and missing. That is not what the telemetry shows.
Wordfence deployed a blocking rule on October 28 at 20:30 UTC, about three hours after the release. The first hit arrived nine minutes later. Across the next 21 hours they counted more than 18,500 requests aimed at staged setup-config.php installer paths. Two of the largest sources did not spray the whole internet. They picked small groups of sites and asked again and again for about 14.5 hours — the shape of someone trying to be present at the exact moment a site starts updating.
That changes the arithmetic. A door that is open for seconds per year is safe from a person and not safe from a machine that never stops knocking. Automated polling turns a lucky guess into a scheduled attempt, and an attacker only needs one success.
There is a second reason this window is less rare than it looks. It opens when a site installs a security release — precisely the moment every site is being told to update. Most WordPress sites take security releases through automatic background updates, so a large share of the web unpacks a full core package within days of the same release. The riskiest moment in this story was not a quiet Tuesday in the future. It was the week you took the fix.
Where the safety net stops
If you run a web application firewall, this is the part to read carefully.
The attack does not load WordPress. It asks for a PHP file directly, which means protections that only run inside WordPress never see the request. Wordfence's own guidance says sites should confirm the firewall is optimized with Extended Protection, so it executes before a direct PHP request reaches the file. A firewall that is installed but not running in that mode is watching the front door while the request comes in through a window.
And the free tier has a delay. Wordfence Premium, Care, and Response customers received the rule on October 28 within about three hours of the release. Wordfence Free receives the same rule on November 27, following their standard 30-day lag.
Read that date again against the timeline above. The exploitation attempts started on day one. If you rely on the free rule, it arrives roughly four weeks after the interesting part of this story. During the window that matters, patching is the only complete fix — not a second layer, the whole thing.
That is not a criticism of a company giving away a product. It is just what the dates say, and it is why the next section is the one to act on.
The belief this breaks
Most site owners carry a reasonable mental model: "It updates itself, so it is handled." That is usually true, and it is worth knowing why it is not the same as confirmed.
An automatic update is a delivery mechanism, not a receipt. It fails quietly when file modifications are disabled because the site is managed through version control or a host's tooling; when the server cannot reach WordPress.org, runs out of disk, or hits a permission error halfway; or when someone disabled auto-updates years ago after a layout broke and never turned them back on.
And it does not apply at all on WordPress 4.6 or older. Those versions no longer receive security fixes, so there is nothing to deliver — the remediation is an upgrade, not a click.
Then there is the branch question, which catches people who did update. Version 7.1.4 covers the 7.1 branch. If your site is on 6.8, the fix came as 6.8.12. On 6.7 it was 6.7.11. On 6.3 it was 6.3.14. The version number you need depends on the branch you are on, and WordPress publishes the full list with each release. A site that updated correctly can still show a number that looks nothing like 7.1.4 and be fully patched — or show 7.1.3 and not be.
The only fact that closes this is the version your site is running right now, read from the dashboard rather than remembered from an email.
What to do this week
Check the number yourself. In the WordPress admin, Dashboard > Updates shows the current version and any pending update, and the At a Glance panel shows it too. Under a minute. The reason to do it by hand is not distrust of automation: silence is ambiguous, and the dashboard is the only place that answers the question directly.
If you are on 4.6 or older, this is an upgrade, not an update. Take a full backup first, then move to a supported release. Plan it as a project with a developer or your host, not a five-minute job, because old sites usually carry old plugins that break on new core versions.
If your files are managed for you — an agency, a host panel, a git deploy — send one message. Name the version you found and ask which release they applied for your branch. Vague answers ("we keep everything current") are how sites stay on 7.1.3 for another month.
Do not treat the firewall as the fix. Even on a paid tier, the rule buys time during the update window; the patched release removes the behavior. On the free tier the rule is not there yet, so this is not a choice.
After any core update, load the site and use it. Visit the homepage, open a product page, submit a form, run a test checkout. An update interrupted halfway is its own kind of outage, and for a shop the failure shows up in the checkout, not in the dashboard.
The other 21 fixes, briefly
The rest of 7.1.4 is narrower, not housekeeping. Most of the remainder are stored cross-site scripting — block delimiters, the Categories block, comment pagination labels, Customizer selective refresh, personal data erasure requests, crafted usernames, image and playlist block handling — plus a cluster in the Interactivity API covering unsafe URL and event-handler bindings, prototype pollution, and a stored denial of service. Most need a Contributor-level account or higher, and several need a privileged user to view attacker-controlled content, which is why they sit below the RCE in urgency rather than in consequence. Stored cross-site scripting is a common route to account takeover.
Two do not need an account at all: an unauthenticated disclosure of unpublished Customizer changes, and an authorization weakness in the Notes REST API for custom roles that can moderate comments but not edit the post a note sits on. The release also refreshes bundled root certificates after the eMudhra revocation.
WordPress credits Anthropic for two of the stored cross-site scripting reports, alongside named researchers from Picus Security, Awesome Motive, VietSunshine, and its own security team.
Key numbers
- 8.1 — CVSS score (Wordfence, high severity, high attack complexity)
- 22 — vulnerabilities fixed in WordPress 7.1.4, released October 28, 2026
- 4.7 — oldest branch that received a backported fix; 4.6 and earlier got nothing
- 9 minutes — time from Wordfence's firewall rule going live to the first exploitation attempt
- 18,500+ — requests against staged installer paths in the first 21 hours
- 14.5 hours — how long the two busiest sources kept polling the same small set of sites
- November 3 — added to CISA's Known Exploited Vulnerabilities catalog
- November 6 — U.S. federal remediation deadline that followed (private sites are not bound by it)
- CWE-367 — the weakness class CISA assigned: time-of-check time-of-use
- November 27 — date the same firewall rule reaches Wordfence Free users
- December 8 — planned WordPress 7.2 release
The takeaway
This flaw is unusual because the thing you are told to do — update — is also the thing that opens the door. That does not make updating the wrong move. It makes checking the version afterwards part of the same move, rather than an optional extra.
The attacker in this story did not need to be clever for long. They needed a script, patience, and a site that had not confirmed its own version number. You cannot do anything about the first two. The third is entirely yours.
Open your dashboard. Read the number. If it is not your branch's patched release, that is the whole job for today.
Not sure where your site stands? Run a free security scan — 40+ automated checks on the public signals that matter, instant results, no commitment.