WordPress Update-Window Flaw Exploited: Patch to 7.1.4 Now
CISA says attackers are exploiting a WordPress core flaw that strikes during the few seconds a site spends updating. Here is what is affected, which versions fix it and how to check your site.
In this article
- What the flaw is and why it is unusual
- What attackers are doing
- Which versions are affected and which fix it
- Why “auto-update” is not enough on its own
- Who should worry most in Nigeria and Africa
- How to check and fix your site
- 1. Confirm your version
- 2. Block web access to the staging folder
- 3. Check your logs
- 4. Look for signs of compromise
- What you should do
- Sources
If you run a business website, a blog or an online shop on WordPress, this one needs your attention today. The US Cybersecurity and Infrastructure Security Agency (CISA) added a WordPress core vulnerability, tracked as CVE-2026-119977, to its Known Exploited Vulnerabilities (KEV) catalogue on 3 November 2026, citing evidence of active exploitation. The fix has been available since 28 October, so the job now is to make sure every site you are responsible for actually has it.
This article is for website owners, web designers who manage client sites, and the IT staff at small businesses who keep the company site running.
What the flaw is and why it is unusual
Most WordPress attacks go after plugins or weak passwords. This one targets WordPress core itself, and it strikes at an unexpected moment: while the site is updating.
When WordPress installs a core update, it unpacks the new release into a temporary staging folder under wp-content/upgrade before moving files into place. On affected versions, those temporary files can be reached from the web for the short time the update is running. That briefly exposes a spare copy of the WordPress installer. An attacker who reaches it before WordPress cleans up could point that staged installation at a database they control, opening a route to running code on the server.
Security researchers describe it as a race condition. No login and no user interaction are needed, but the timing is tight: in Wordfence’s lab tests the window normally lasted only seconds. Wordfence scores the flaw 8.1 (High) on the CVSS scale, while WordPress itself rated it Low. CISA’s decision to list it as exploited is the clearest signal that attackers think the race is worth running.
What attackers are doing
Wordfence pushed a firewall rule for the bug on 28 October and recorded its first match nine minutes later. Reports since then describe large volumes of requests aimed at staged installer paths, especially setup-config.php files under wp-content/upgrade. Researchers stress that blocked requests are scanning, not proof that a site was taken over, and CISA has not named the attackers or said how many sites were compromised.
Which versions are affected and which fix it
The flaw affects WordPress 4.7 through 7.1.3. The main fix is WordPress 7.1.4, and WordPress back-ported fixes to older branches as well. Examples of the fixed versions per branch include:
- 7.1 branch: 7.1.4
- 7.0 branch: 7.0.8
- 6.9 branch: 6.9.11
- 6.8 branch: 6.8.12
- 6.7 branch: 6.7.11
- Oldest covered branch, 4.7: 4.7.39
WordPress 4.6 and older get no fix at all, and WordPress only actively supports its latest release, so moving to 7.1.4 is the best choice where your theme and plugins allow it.
The 7.1.4 release also fixes other issues, including stored cross-site scripting problems, a stored denial-of-service bug in the Interactivity API, and a leak of unpublished Customizer changes. It also updates the bundled root certificates after the recent eMudhra distrust.
Why “auto-update” is not enough on its own
Many sites receive minor core updates automatically, but background updates can be disabled by hosts, by settings in wp-config.php, or simply fail. Do not assume. Confirm the version number on every site.
Who should worry most in Nigeria and Africa
WordPress powers a large share of small-business, NGO, school and media websites across the continent, often on shared hosting managed by a freelancer or an agency. Those setups are exactly where updates get missed: the person who built the site may have moved on, auto-updates may be switched off to “avoid breaking things”, and nobody is reading the server logs. Agencies that look after dozens of client sites should treat this as an inventory exercise, not a single click.
How to check and fix your site
1. Confirm your version
In the WordPress dashboard, open Dashboard > Updates. The page shows your current version and offers the security release if it is missing. If you use WP-CLI, the command wp core version shows the installed version, and wp core update installs the newest release.
2. Block web access to the staging folder
Until every site is patched, and as a lasting safeguard, block public access to wp-content/upgrade. Put the rule in your main web server configuration or the site’s root .htaccess, not inside the upgrade folder, because WordPress empties that folder during updates. On Apache a rewrite rule that returns “Forbidden” for that path works; on Nginx a location block with deny all does the same. Ask your host to do this if you cannot.
3. Check your logs
Ask your host for web server access logs, not just WordPress logs, and look for requests to PHP files under /wp-content/upgrade/, especially setup-config.php. WordPress never requests that folder over the web, so such requests are suspicious. A successful (200) response close to the time of one of your core updates deserves urgent follow-up.
4. Look for signs of compromise
After updating, review administrator accounts for anyone you do not recognise, check for plugins you did not install, and look for unfamiliar PHP files changed since 28 October. If you use WP-CLI, wp core verify-checksums compares core files with the official release. If anything looks wrong, treat the site as compromised: keep the evidence, restore from a known-good backup, and change the database password, security salts and admin passwords.
What you should do
- Today: update every WordPress site to 7.1.4, or at least the fixed version for its branch, and confirm the version number afterwards.
- Block web access to wp-content/upgrade at the server level.
- Review access logs and admin accounts for anything unusual since late October.
- Keep a web application firewall as an extra layer, but never as a replacement for patching.
- Remember plugins and themes are separate: this release fixes core only, so update those too.
Sources
Was this article helpful?
adminVerified expert
Cybersecurity Analyst — 20 years experience
Federal Capital Territory (Abuja)
Credentials: MCPN, MNCS, IAENG | System Analyst · Web Developer · CEH · CC · CDST
Got expertise to share? Write for us →
