← All articles

Your WordPress Site Was at Risk While It Updated: What CISA's Nov 3 Warning Means for Small Businesses

By Front Range Cybersecurity ·

Most small business owners have learned one rule about websites: keep them updated. That still holds. But a WordPress flaw that U.S. officials flagged last week is a strange case. The risk shows up during the update itself.

On November 3, 2026, the Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog. CISA adds a flaw to that list only when it has evidence that attackers are using it. If your business runs a WordPress site, or used to, this post explains what happened, why it matters, and what to check this week.

What happened: a WordPress core flaw that CISA confirmed attackers are using

CVE-2026-119977 sits in WordPress core, the base software every WordPress site runs, not in an add-on plugin or theme. CISA's KEV entry describes it as a "time-of-check time-of-use (TOCTOU) race condition vulnerability that could allow unauthenticated attackers to execute code on the server during the upgrade window." CISA says the cause is "predictable, web-accessible staging paths used during full-package core upgrades."

The WordPress project fixed it in WordPress 7.1.4, released October 28, 2026. The release notes list "a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window," reported by Umut Bayram. The same release fixes several other issues, mostly stored cross-site scripting bugs. The WordPress team's advice was blunt: "Because this is a security release, it is recommended that you update your sites immediately."

Here is the timeline as reported:

  • October 28: WordPress releases 7.1.4.
  • The following days: According to The Hacker News, the WordPress security company Wordfence reported more than 18,500 requests aimed at staged setup-config.php installer paths in the first 21 hours after public disclosure. The same report says the threat-intelligence firm Previdian saw exploitation attempts against its honeypots on October 30.
  • November 3: CISA adds the flaw to KEV.

Reporting from BleepingComputer and The Hacker News describes it as high severity (The Hacker News cites a CVSS score of 8.1). It is not described as easy to exploit. BleepingComputer calls these "high-complexity attacks," and the attacker has to hit a short window while a full core update is running. Still, "hard to pull off" and "being tried thousands of times a day" can both be true. Attackers automate this kind of thing.

Why "the update window" is the risky part

Most security advice treats an update as the moment you become safe. This flaw turns that around for a short time. Here is a plain-English version.

When WordPress performs a full-package core upgrade, it unpacks the new files into a temporary staging location before moving them into place. According to CISA, those staging locations were predictable and reachable from the web. That combination is the problem.

A "time-of-check time-of-use" race works like this. The software checks that something is safe, and a moment later it uses it. If an attacker can step into the gap between the check and the use, the earlier check no longer means much. Here, the gap is the upgrade window. If an attacker can guess where the staged files are and reach them over the internet before the upgrade finishes, the attacker may be able to run code on the server without logging in. The reported attack traffic targeted staged copies of setup-config.php, the WordPress installer script.

Two practical takeaways for non-technical owners:

  1. "We keep it updated" is not the same as "we're on the fixed version." The protection comes from running WordPress 7.1.4 or later. Upgrades to that version, or any full-package upgrade on older code, are exactly where the weakness lives.
  2. The risky moment can be invisible. Many sites update automatically in the background. Nobody is watching when the window opens.

Who should care

You should pay attention if any of these sound familiar:

  • You run a self-hosted WordPress site. That includes sites on shared hosting, managed WordPress hosting, or your own server. (Sites hosted on a platform where you never see a version number or an "Updates" screen are a different situation. Ask your provider.)
  • An agency or freelancer built your site and you are not sure who handles updates now. That kind of site often runs for years without anyone clearly owning it.
  • You have forgotten or "temporary" sites. Old campaign landing pages, a staging copy from the last redesign, a microsite for an event, a blog on a subdomain. If it's on the internet and running WordPress, it counts.

We don't have data on how many small business sites are affected, and we won't guess. The useful question is narrower: which WordPress installs do you own, and what version is each one on?

What to do this week

These steps don't require deep technical skill. If you get stuck, your hosting provider or web developer can help.

1. Confirm each site is on WordPress 7.1.4 or later

Log in to the WordPress dashboard and go to Dashboard → Updates. The page shows your current version. If it is older than 7.1.4, update now. You can also check the "At a Glance" box on the main dashboard.

The WordPress team notes that fixes were also backported to older supported branches, and that "only the most recent version of WordPress is actively supported." If you're on an older branch, ask your developer about moving to current.

2. Check your hosting provider's update status

If your host manages WordPress updates for you, don't assume. Look for a status page, a support article, or an email about 7.1.4, or open a ticket and ask:

  • Has my site been updated to 7.1.4 or later?
  • When did that happen?
  • Do you have extra protections for the upgrade process?

Write down the answers. They help with the next steps.

3. Find every WordPress install you own

This is the step most businesses skip, and it matters most. Make a simple list of:

  • Every domain and subdomain your business uses (check your domain registrar account)
  • Every hosting account you pay for, including ones set up by past employees or vendors
  • Any staging, test, or "dev" copies of your site

Then check the WordPress version on each one. If a site no longer serves a purpose, consider taking it offline rather than maintaining it.

How to check for signs of compromise

Because exploitation happened before CISA's warning, updating fixes the hole going forward, but it doesn't tell you whether someone got in earlier. CISA's own guidance for federal agencies calls for forensic triage on this flaw. That federal directive (BOD 26-04) applies only to federal civilian agencies, not to private businesses. The idea behind it is still sensible: after patching, look for signs that someone got in before you did.

General things to look for, or to ask your host or developer to check:

  • Unexpected admin users. Go to Users in the dashboard and filter by Administrator. Remove or question any account you don't recognize.
  • New or unfamiliar files in your WordPress directories, especially PHP files that appeared recently in places you wouldn't expect.
  • Requests for setup-config.php in your web server logs, particularly around the time your site last updated. Those requests alone don't prove a compromise, since automated scanners try them all the time. But they are worth raising with your host.
  • Unexpected plugins, changed content, strange redirects, or spam pages showing up in search results for your domain.

If anything looks off, don't just delete it and move on. Contact your hosting provider or a qualified security professional so they can confirm what happened and whether anything else was touched.

Why KEV is a useful priority list for small teams

Small businesses can't patch everything at once, and they shouldn't have to read every security bulletin. CISA's KEV catalog helps here. It is a public, free list of vulnerabilities that are confirmed to be exploited in the wild, not just theoretically possible.

In its announcement, CISA says it "encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities." For a small team, that becomes a simple habit:

  1. Keep a list of the software you have exposed to the internet: website platforms, VPNs, firewalls, email and file-sharing tools.
  2. Glance at new KEV additions every week or two.
  3. If something on your list shows up, treat it as urgent.

For this specific flaw, the KEV entry lists "Known To Be Used in Ransomware Campaigns?" as Unknown. That isn't a reason to relax. It means there's no public confirmation either way.

Where an outside look fits

The hardest part of this kind of alert is usually not the patch. It's knowing that the forgotten staging site or old landing page exists at all. That's why many businesses get an external view of what they have facing the internet, and which versions those systems are running. It tends to surface the systems nobody remembers owning.

You can start on your own. If you want more background, see our posts on patching internet-facing systems first, how many external IP addresses your business has, and PHP vulnerabilities and small business websites.

For a free list of security basics, including keeping an inventory of internet-facing systems, see the SMB Security Checklist.

The short version: confirm WordPress 7.1.4 or later on every site you own, ask your host what they did and when, find the WordPress installs you forgot about, and check for signs someone got in before the fix.

Sources