WordPress Hacked After Update? Audit the CVE-2026-119977 Window

The WordPress 7.1.4 security release fixes CVE-2026-119977, an actively exploited core flaw, but the old, vulnerable updater is what installs it, which can leave a site open for a few seconds. If you suspect your WordPress site was hacked after the update, here is how to check, and how to close that window before you patch.

Did WordPress already update before you could prepare?

If your site moved to WordPress 7.1.4 or a matching branch fix this week, the update ran through a short window in which the site could be attacked. CVE-2026-119977 affects WordPress 4.7 through 7.1.3; the fix shipped in 7.1.4 and in parallel releases for every older branch back to 4.7. CISA added the flaw to its Known Exploited Vulnerabilities catalog earlier this week based on evidence of active exploitation, though it did not describe the attacks.

The twist, found by Umut Bayram of Picus Security: the fix cannot protect its own installation. The old updater already on disk unpacks the new release, and that updater is the vulnerable part.

Automatic background updates use the same updater, so a site that patched itself at 3 a.m. passed through the same window as one whose admin clicked Update Now. WP-CLI’s wp core update calls the same updater and unpacks into the same folder. One reassurance: if your server already refused web requests to wp-content/upgrade with a 403, the temporary installer was never reachable from outside.

What could those few seconds change on a live site?

An attacker could gain code execution on your server. During a core update that uses a complete package, WordPress expands a full copy of the new release, installer included, into a temporary folder under wp-content/upgrade, and on most hosts the web server will serve files from that folder to anyone who asks.

A stock release ships with wp-config-sample.php, not your real wp-config.php, so the unpacked copy looks like a fresh, uninstalled WordPress. An unauthenticated attacker who knows the folder name and reaches the installer before WordPress deletes the copy can set it up against a database they control, log in, and run PHP with the web server’s permissions.

From there they can read and write files in the live site. That does not automatically mean root, but a WordPress install that can update itself usually lets the web server account write to core, plugin and theme files, which is enough for a persistent backdoor.

Before the fix there was a second path: the installer could write a new wp-config.php into the temporary copy, and the update would copy it over your real one, replacing your database credentials, table prefix, and authentication keys and salts. The fix blocks this overwrite even during its own installation, because WordPress copies files into place using the new code. For this week’s update, code execution is the path that matters.

Which sites were really exposed during the fix?

Exposure came down to your starting version, the package WordPress downloaded, and whether a scanner happened to hit at that moment.

• Folder name. On 5.9 and later, the old updater names the temporary folder after the downloaded file, so the name is predictable one last time. On 4.4 through 5.8, it adds random characters, which hides the folder unless the site leaks it some other way, such as in an error message.
• Package type. Complete packages always include the installer files. A partial package, built for one specific starting version, exposes a site only if it happens to contain them. On November 6, WordPress.org offered partial packages for within-branch moves such as 7.1.3 to 7.1.4, including automatic updates, and only complete packages for branch jumps such as 7.0.7 to 7.1.4.
• Fallbacks. WordPress falls back to a complete package when core files fail the official checksums (common on hand-edited or already infected sites) or when the update is a reinstall.

Bayram put it plainly in a November 6 statement to The Hacker News: the deciding factor “isn’t partial versus complete. It’s whether the updater already installed on the site has been fixed.”

The window is short; the scanning that follows is not. Wordfence measured the window at only seconds in its lab, yet saw attack attempts begin nine minutes after it deployed a firewall rule on release day. Two of the busiest sources kept checking small groups of sites for about 14.5 hours, a pattern the company says fits attempts to catch sites mid-update.

Public GitHub repositories also hold code its authors describe as an exploit, including one that claims to work on sites still using a predictable folder during complete-package updates. It is unverified.

Not updated yet? Install 7.1.4 with the window closed

Block web access to wp-content/upgrade first, then update. Bayram notes that WordPress works with that folder directly on disk, so blocking web access does not break updates. Only an attacker needs a browser to reach it.

1. Deny the folder in the server configuration. On Nginx, add location ^~ /wp-content/upgrade/ { deny all; } to the active server block and reload. On Apache, add Require all denied inside a <Directory> block for that folder in the virtual host configuration. If a reverse proxy or CDN sits in front, enforce the block there too.
2. On .htaccess-only hosting, use the root file. Add RedirectMatch 403 ^/wp-content/upgrade/ to the .htaccess file in the WordPress root, above the WordPress rewrite rules. Do not put an .htaccess file inside wp-content/upgrade: the old updater empties that folder before it unpacks an update, so the file would vanish exactly when you need it.
3. Test from outside. Request /wp-content/upgrade/ from a different network and confirm you get a 403. An untested rule is a guess.
4. Turn on a firewall rule for CVE-2026-119977. A SiteGuarding website firewall with a signature for this flaw adds a second layer while the update runs, as backup to the deny rule, not a substitute.
5. Update, then verify. Confirm the dashboard shows 7.1.4 or your branch’s fixed release, and that wp-content/upgrade is empty.

The other safe route is a manual update: back up the files and database, unpack the new release in a folder the web server does not serve, copy the core files into place without touching wp-config.php or wp-content, then run the WordPress database update.

Keep automatic updates on. Once the fix is in, later updates use a random folder name and never copy a wp-config.php from the temporary copy over the real one. Sites on 4.6 or earlier get no fix at all; Bayram’s advice is to move them to a supported version.

Already updated? How to check WordPress after the update

Preserve evidence before you delete anything: clearing the upgrade folder or reinstalling core first wipes the timeline you need. Take a filesystem snapshot, copy the access logs covering the update, then work through this list:

• Pin down the update time. WordPress emails the admin address after automatic background updates; the modification time of wp-includes/version.php is another marker.
• Read the access logs around that time. Look for outside requests to any PHP file under wp-content/upgrade, such as install.php or setup-config.php, especially any that returned 200. A normal update never produces those.
• Compare wp-config.php with a backup. A changed database host, name or table prefix, or defines you never added, is a red flag.
• List administrators. Look for accounts you don’t recognize and any admin created near the update. Check for plugins nobody installed while you are there.
• Hunt for new PHP files. Sort by modification time across wp-content/upgrade, wp-content/uploads, mu-plugins, plugins and themes. Uploads should almost never hold PHP.

Practitioner’s note: in hack-recovery work, we often see a clean core checksum result reported as “the site is clean.” Checksums flag changes to files WordPress ships, not extra PHP files dropped beside them, and plugin checksum checks often skip commercial or privately distributed plugins.

A webshell in uploads or a fake plugin in mu-plugins passes a core checksum every time, so compare against a known-good backup or staging copy, folder by folder.

If anything looks wrong, assume the attacker read wp-config.php. After containment, rotate the database password, regenerate the authentication keys and salts (this logs everyone out), and reset every administrator’s credentials.

Why does WordPress rate it low when CISA lists it as exploited?

The ratings answer different questions. Wordfence, which assigned the CVE, scored it 8.1, in the High band of CVSS. WordPress’s own advisory rates it low. Neither figure tells you whether your site was hit. CISA’s listing is a separate signal: someone is exploiting it.

Much remains unknown. CISA has not described the attacks, the GitHub code is unverified, and the reporting carried no indicators of compromise. Bayram traces the behavior to WordPress 2.7 in 2008, roughly 18 years of the same unpacking pattern, though that origin rests on his analysis. For IOCs as they appear, follow the WordPress and Wordfence advisories.

When does a WordPress site need a full cleanup?

The moment you find a confirmed trace: a successful installer request, an unknown admin, an altered wp-config.php, or PHP in uploads. At that point a scan is only a starting point. Attackers who reach code execution rarely plant a single backdoor, and missing the second one usually means reinfection within hours.

Clean from the snapshot outward: identify every added file, restore core, plugins and themes from trusted sources, rotate credentials, then keep watching. Continuous file-change monitoring with SiteGuarding Antivirus catches a quiet backdoor that reactivates days later. If Google has already flagged the site, our guide to removing a “This site may be hacked” warning walks through the Search Console review.

FAQ

Can updating WordPress get your site hacked?

With CVE-2026-119977, yes, briefly. The update to 7.1.4 is unpacked by the old vulnerable updater, which can expose a temporary WordPress installer for a few seconds.

Is WordPress 7.1.4 safe if it already installed itself?

Yes, 7.1.4 and the branch fixes are not vulnerable. The open question is whether anyone hit the site during the install, so check the logs, admin accounts, wp-config.php and any new PHP files.

Is wp core update safer than updating in the dashboard?

No. WP-CLI runs the same updater and unpacks into the same wp-content/upgrade folder; only a manual update unpacked outside the web root avoids the exposure.

Does blocking wp-content/upgrade break WordPress updates?

No. WordPress works with that folder directly on disk, so denying web access only stops outside requests. Put the rule in the server config or the root .htaccess, never inside the folder itself.

Found a stranger in your admin list or PHP where it doesn’t belong? Our team handles hack recovery and firewall setup for WordPress sites: choose a protection package and we’ll take it from there.