CybersecurityWebsites

How to Patch the WordPress Update Flaw Attackers Are Now Using

CISA says attackers are exploiting a WordPress flaw that opens during core updates. How a small business confirms 7.1.4 and closes the upgrade folder this week.

By Cybercave Technologies, LLC · Nov 4, 2026

A silver laptop with a blank white screen on a white table beside a white globe lamp, against a plain white wall — A laptop on a desk. Illustration only, not a site or system named in this article. Credit: Photo by Hanna Pad via Pexels (Pexels License).

Short answer: A WordPress flaw lets someone with no login run code on your server during the few seconds a core update unpacks, and the US cyber agency CISA says attackers are exploiting it. Fix it in two moves: make sure your site runs WordPress 7.1.4 or your branch's patched release, and have your host block web access to the wp-content/upgrade folder.

Key points

WordPress released version 7.1.4 on Oct. 28 as a security release and told site owners to update right away. One of its fixes closes a weakness in the update process that could lead to code running on the server.
The Cybersecurity and Infrastructure Security Agency (CISA) added the flaw, CVE-2026-119977, to its list of exploited vulnerabilities on Nov. 3, citing evidence of active exploitation.
Security firm Wordfence counted more than 18,500 requests aimed at the temporary installer files in the first 21 hours after the flaw was disclosed, The Hacker News reported.
The WordPress advisory lists every version from 4.7.0 through 7.1.3 as affected, with fixes for each branch back to 4.7.39.

What to do this week: log in to your WordPress dashboard, open Dashboard > Updates, and confirm the version shown is 7.1.4 (or the patched release for your branch). Then ask whoever hosts your site to deny web access to the wp-content/upgrade folder.

What did attackers find in WordPress?

They found a gap that opens every time WordPress updates itself with a full package. For a few seconds, a complete copy of the new WordPress files sits in a folder anyone on the internet can reach.

The WordPress advisory says the update unpacked new files into a predictable folder inside the web-served upgrade directory, and an attacker who wins the race against that unpacking could run code on the server. No account on the site is needed.

Patchstack, a WordPress security company, explains the mechanics: the temporary copy includes the WordPress installer file, setup-config.php, which can start up without your site's settings. An attacker who reaches it in time can run the installer against a database the attacker controls, inside your site's own folders.

Think of a contractor who props the back door open for ten seconds while carrying in new cabinets. Most days nobody notices. Someone who waits by that door all day will eventually get in.

Is it really being used in attacks?

CISA says yes, though it hasn't shared details. Its catalog entry, added Nov. 3, says someone with no login could run code on the server while a core update is under way, and it gives federal agencies until Nov. 6 to act. That deadline binds only federal agencies, but CISA urges every organization to prioritize the flaws on this list.

BleepingComputer notes that CISA gave no details about the attacks, and reported that Wordfence said over the weekend it had blocked 13,095 attacks on this flaw in 24 hours.

That 18,500-request count works out to about 880 tries an hour (our calculation: 18,500 divided by 21 hours). Attackers can't know when your site will update, so they keep asking.

The experts don't fully agree on the danger. WordPress's own advisory rates it Low. Patchstack calls the window tiny and says it would not call the attack practical, while The Hacker News reports a high-severity score of 8.1 out of 10 on the standard CVSS scale. Our reading: CISA's listing settles the practical question, so plan as if someone is trying it on your site.

Why does this matter for a small-business website?

Because the risky moment is an ordinary update, and most small-business WordPress sites update on their own. WordPress says sites with automatic background updates will start the 7.1.4 update by themselves, and each future full update is another window until the fix is in.

A security plugin alone may not stop it. Patchstack says a firewall that runs inside WordPress can't block this request, because the temporary copy loads its own files and never runs your site's plugins.

Our example (hypothetical): a Holland bakery's WordPress site takes orders and shows the weekly menu. If someone runs code on that server, they could change the order page, add a fake payment link or plant spam pages, and the owner might not notice for weeks.

How do I check and fix my WordPress site?

Check your version. Log in and open Dashboard > Updates. You want 7.1.4, or for older branches a patched release such as 7.0.8, 6.9.11 or 6.8.12, per the WordPress advisory.
Update if it hasn't happened. WordPress says to click Update Now on that screen. Back up the site first if your host doesn't do it for you.
Close the upgrade folder. Ask your host or web person to deny web access to wp-content/upgrade at the web server and make sure the folder can't be listed. Patchstack recommends exactly this step.
Look for anything you didn't add. Our advice: in Users, filter by Administrator and remove any account you don't recognize; in Plugins, check for anything you didn't install.
Ask about every site you own. Old landing pages, a second store and test copies run WordPress too. Each one needs the same check.

For your IT provider: CVE-2026-119977, CWE-367 (time-of-check time-of-use race), affects WordPress 4.7.0-7.1.3, advisory GHSA-4w3m-c66w-69mg. Fixed in 7.1.4 and backports 7.0.8, 6.9.11, 6.8.12 and down to 4.7.39. Per Patchstack, 7.1.4 adds 16 random characters to the staging folder name and recreates its index.php. Deny HTTP access to /wp-content/upgrade/ in the server or virtual-host config, not in a PHP firewall, and review access logs for requests to setup-config.php under that path around update times. CISA's entry marks forensic triage as required for federal agencies.

What should you do this week?

Open Dashboard > Updates on every WordPress site you run and confirm it shows 7.1.4 or your branch's patched release. Then send your host one sentence: "Please block web access to wp-content/upgrade on my site." Both take minutes, and once the patched version is in, this gap stays closed for future updates.

For more, see our guides to checking the outside scripts on your business website, asking your web host about server patches, and testing that your backups actually restore.

FAQ

My site updates automatically. Am I covered? Probably, but check. WordPress says sites with background updates will install 7.1.4 on their own; the version on Dashboard > Updates tells you whether it happened.

My site was built on another platform. Does this affect me? Only if your site runs WordPress software. This flaw is in WordPress itself, so it matters for any WordPress site, including one a developer set up for you years ago. If you're not sure what your site runs, ask whoever built it.

Does a WordPress security plugin protect me? Not by itself here. Patchstack says the attack goes straight to the temporary files and skips your plugins, so the fix is the update plus a block at the web server.

What is the CISA exploited-vulnerabilities list? It's CISA's catalog of flaws it has evidence attackers are using. Federal agencies must fix them by a deadline, and CISA urges everyone else to treat them as top priority.

Disclosure: No company or organization named in this article paid for it, reviewed it or saw it before publication. Cybercave Technologies builds, hosts and manages websites for small businesses and offers AI automation services. Version numbers, dates and counts are as published by the organizations named and were checked on Nov. 4, 2026. Not sponsored.