WordPress Core Update Hack: CVE-2026-119977 Under Active Attack

CISA added CVE-2026-119977, an actively exploited flaw in WordPress Core, to its Known Exploited Vulnerabilities catalog on November 4, 2026. It is a WordPress core update hack in the most literal sense. For a brief window during a routine full upgrade, an attacker with no login can run code on your server, which puts nearly every WordPress site in scope.

Why is a WordPress core update a risk this week?

A WordPress core update is risky this week because attackers are exploiting a bug in the update process itself. On November 4, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2026-119977 to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation. The flaw is rated high severity, with a CVSS score of 8.1.

This bug lives in WordPress Core itself, not in a form plugin, a page builder or an abandoned theme. WordPress powers a large share of the public web, so a core flaw scales with the entire install base. If you run WordPress on a public server, assume you are in scope until you confirm otherwise.

Reporting so far names no attacker group and publishes no IPs, domains or file hashes. A blocklist will not help here. Patching, a short update window and a proper check afterward will.

How does the WordPress core update hack work?

The attack only works while a full-package core upgrade is running, and it requires no login. CISA describes a time-of-check time-of-use (TOCTOU) race condition that “could allow unauthenticated attackers to execute code on the server during the upgrade window.” The root cause, in CISA’s words, is “predictable, web-accessible staging paths used during full-package core upgrades.”

Put simply, when WordPress replaces its entire core, it stages new files in temporary locations before moving them into place and cleaning up. Those locations are guessable, and the web server will serve them. Between the moment the updater checks a file and the moment it uses or removes it, there is a gap. A request that lands in that gap can interfere with what the updater does next.

Wordfence, which published details about a week before the KEV listing, described both the low bar and the catch. Exploitation “does not require an account on the site,” but the attacker must hit the brief window while a complete core update is in progress. That window opens only occasionally, since many routine minor and security releases install in the background without a full-package upgrade.

That makes the attack a numbers game. Race conditions are probabilistic, so attackers do not need to beat you specifically. They need to win somewhere, and they hammer staging paths across thousands of sites to do it. When one race lands, the result is code execution as the web server user. In practice, that means the entire site: its files, its database credentials, and a foothold for whatever comes next.

How much scanning is already hitting WordPress sites?

Scanning is heavy and started within hours. Wordfence said it recorded more than 18,500 requests aimed at staged setup-config.php installer paths in the first 21 hours after public disclosure, about 880 an hour. It also said it blocked 12,632 exploitation attempts in the 24 hours before The Hacker News published its report on November 4, roughly nine a minute. These figures come from one vendor’s sensor network, so they show the shape of the activity rather than a global total.

Independent telemetry points the same way. Previdian recorded three exploitation attempts against its honeypot sensors on October 30, 2026, from an IP address geolocated in the United Kingdom. Geolocation is not attribution; scanners often run from rented or hijacked machines.

The target file is a useful clue. setup-config.php is a legitimate part of the WordPress installation wizard, used once to create wp-config.php on a fresh install. On a configured live site, no outside visitor should be requesting staged copies of it. Volume is likely to rise now that the KEV listing has drawn wider attention to the bug.

How should you update WordPress core without leaving the door open?

Update now, deliberately, and keep the exposed window as short as possible. Patches have been available since late October 2026, and every unpatched day gives attackers another chance to catch your next upgrade.

1. Confirm what you run. Open the Updates screen in the dashboard to see your core version and whether a newer release is offered. Check the current release notes on WordPress.org, or ask your host whether your install includes the late-October security fix.
2. Back up off the server. Take a full file and database backup and store it where the web server cannot write.
3. Update from a clean machine. If the laptop holding your WordPress, hosting panel and SFTP credentials is compromised, patching the server buys little.
4. Close the window. Pick a quiet hour, enable maintenance mode, and if your firewall allows it, restrict wp-admin and the upgrade directory to your own IP while the update runs.
5. Finish what you start. An interrupted upgrade can leave staging files on disk long after the window should have closed. Confirm wp-content/upgrade is empty and no stray installer files remain.

CISA gave U.S. Federal Civilian Executive Branch agencies until November 6, 2026, to apply fixes. That deadline binds only those agencies, but it is the clearest urgency signal available, and small business sites face the same scanners.

Automatic updates cut the delay between release and install. They do not shrink the race window, and they do not tell you whether someone got in. A website protection package with a firewall that blocks installer and staging paths outside maintenance hours closes most of that gap, and file monitoring flags unexpected core changes.

What should you inspect if the update already ran?

Check logs, core files, users and uploads, because a finished update proves nothing about what happened during it. If an attacker won the race, the update still completes and the homepage still loads.

Logs

Find when your last full core upgrade ran (dashboard, host panel or file dates). Search access logs around that time for outside requests to setup-config.php, wp-content/upgrade and update-related paths in wp-admin. Bursts of 404 or 403 responses from one source mean you were being polled. A 200 response to a staged path from an unknown address during the window needs a closer look.

Core files and persistence

Verify core files against the official checksums; WP-CLI’s checksum command flags modified or extra files. Then look for:

• Administrator accounts you did not create, or existing admins with changed emails.
• PHP files in wp-content/uploads, which should hold media only.
• New entries in mu-plugins, unfamiliar scheduled tasks, and edits to .htaccess or .user.ini.
• Recently modified theme files such as functions.php and header.php.

With no published hashes or IPs, you are hunting anomalies, not matches. A full antivirus scan of files and database catches obfuscated code that is easy to miss by eye.

Practitioner’s note: In hack recovery work, the failure we see most is partial cleanup. The owner deletes the visible spam or redirect, the site looks fine for a week, then it all returns. Code execution as the web user means any writable file could carry a backdoor. Find one, assume more, and rotate every password, the salts in wp-config.php, and database and SFTP credentials.

If Google has already flagged the site, that needs its own review. Our guide on removing a hacked-site warning in Google covers the sequence.

What is still unknown about CVE-2026-119977?

Several basics are still missing. The public reporting does not state which WordPress versions are affected or which release contains the fix. It names no threat actor or campaign, and it offers no indicators beyond the generic setup-config.php path string.

It also does not say whether sites on managed hosts with automatic updates were exposed, or whether some server setups already block web access to staging directories. Only your host can answer that for your account.

Until official release notes and the CVE record fill these gaps, treat every unpatched WordPress site as a priority and every site that ran a full core upgrade since disclosure as one to check.

FAQ

Does CVE-2026-119977 affect plugins and themes?

No. The flaw sits in WordPress Core's full-package upgrade process, so it affects the core install itself regardless of which plugins or themes you use.

Can someone exploit CVE-2026-119977 without a WordPress account?

Yes. CISA and Wordfence both describe it as unauthenticated. The catch for the attacker is timing: the request has to land while a full core upgrade is in progress.

Which WordPress version fixes CVE-2026-119977?

Patches were released in late October 2026, but the public reporting does not name the fixed version. Check the WordPress.org release notes or ask your host to confirm your install includes the fix.

I already updated WordPress. Do I still need to check the site?

Yes. If an attacker won the race during that update, the upgrade still finishes normally. Check access logs around the update time, verify core checksums, and review admin accounts and the uploads folder.

Why does CISA's November 6 deadline matter if I am not a U.S. agency?

The deadline legally applies only to U.S. federal civilian agencies. It still tells you CISA considers the flaw urgent, and private sites face exactly the same scanning.

Does automatic WordPress updating stop this attack?

No. It shortens the time you stay unpatched, but the race window exists during the upgrade itself, so a post-update check is still needed.

If your logs or file checks turn up something you cannot explain, do not just delete the visible symptom. Our website protection and cleanup packages combine malware removal, a website firewall and ongoing monitoring so the next core update does not reopen the door.