Hackers Are Targeting a WordPress Flaw That Exposes Websites During Updates

Hackers are exploiting a high-severity vulnerability in WordPress that could allow them to take control of a website while its Core software is being updated. The flaw, tracked as CVE-2026-119977, affects WordPress versions 4.7 through 7.1.3 and can allow unauthenticated attackers to execute code on an affected server.

The US Cybersecurity and Infrastructure Security Agency (CISA) added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalogue on November 3, confirming that it is being exploited in the wild. WordPress released security fixes on October 28, but there is an important complication: the first update that installs the fix can itself leave a temporary window of exposure on some sites.

How the WordPress vulnerability works

The weakness is a time-of-check to time-of-use (TOCTOU) race condition in the WordPress Core upgrade process. It can expose a temporary copy of the website while certain updates are being installed.

• A temporary copy is created: During some full-package Core updates, WordPress extracts installation files into a temporary directory under wp-content/upgrade/.
• The installer can become reachable: On affected installations, the temporary files may be accessible through the website. This can expose the staged WordPress installer, including setup-config.php.
• An attacker tries to win the timing window: The attacker does not need a WordPress account, but must reach the temporary installer while the files are present and before the update process removes them.
• The configuration file can be replaced: Researcher Umut Bayram of Picus Security found that an attacker who wins the race can place a malicious wp-config.php in the temporary installation. During the vulnerable update process, it can be copied over the site’s live configuration file.
• The attack can lead to server-level code execution: The replacement configuration can point WordPress to an attacker-controlled database. On a typical single-site installation, the attacker may then create an administrator account and use a malicious plugin to execute PHP code on the server.

Wordfence’s testing found that the opportunity normally lasts only seconds. The attack is therefore highly dependent on timing and the conditions of the update. It is not a vulnerability that automatically gives an attacker access to every WordPress site.

What the exploitation evidence tells us

• CISA confirmed exploitation: The agency added CVE-2026-119977 to its KEV catalogue on November 3. This is an important warning that attackers have exploited the vulnerability, rather than it being only a theoretical security issue.
• More than 240,000 requests blocked: Wordfence reported on November 5 that its firewall had blocked over 240,000 exploit attempts. More than 74,000 requests were blocked on October 30 alone.
• Those figures are not hacked-site numbers: The Wordfence figures count blocked requests, not unique websites or successful compromises. Automated scanners can send repeated requests to many sites.
• Some additional activity has been observed: The Hacker News reported three exploitation attempts recorded by Previdian honeypot sensors, including activity from an IP address geolocated in the UK. These were attempts against monitored decoys, not confirmation that three real websites were breached.
• Confirmed victims remain unclear: The public reports reviewed for this article do not establish how many websites were successfully compromised. They also do not identify confirmed victims or establish that customer or website-owner data was stolen.

Which WordPress versions are affected?

The published vulnerability information identifies WordPress Core versions 4.7 through 7.1.3 as affected. WordPress has issued fixes for multiple older release branches as well as the current branch.

• 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
• 6.6 branch: 6.6.11
• 6.5 branch: 6.5.14
• 6.4 branch: 6.4.14
• 6.3 branch: 6.3.14
• 6.2 branch: 6.2.15
• 6.1 branch: 6.1.16
• 6.0 branch: 6.0.18
• 5.9 branch: 5.9.20
• 5.8 branch: 5.8.19
• 5.7 branch: 5.7.21
• 5.6 branch: 5.6.23
• 5.5 branch: 5.5.24
• 5.4 branch: 5.4.25
• 5.3 branch: 5.3.27
• 5.2 branch: 5.2.30
• 5.1 branch: 5.1.28
• 5.0 branch: 5.0.31
• 4.9 branch: 4.9.35
• 4.8 branch: 4.8.34
• 4.7 branch: 4.7.39

Website owners should use the fixed release for their own branch, rather than assume that any version newer than the one they currently run is protected. WordPress recommends using the latest release where possible. Sites running WordPress 4.6 or older should plan a move to a supported version rather than rely on those older releases for security protection.

Why installing the fix needs extra care

There is a detail that makes this vulnerability particularly important for site owners. Researcher Umut Bayram explained on November 5 that the first update from an affected version can still create a final, package-dependent exposure window.

• The old, vulnerable updater is responsible for initially extracting the update files.
• That means the temporary directory can still be created using the old process before the fixed updater code takes over.
• Not every update package contains the installer files needed for this attack, so the exposure is not identical for every update.
• Automatic background updates use the same underlying updater process. They should not be assumed to avoid this issue.

The researcher recommends blocking public web access to /wp-content/upgrade/ before installing the first security update. This reduces the opportunity to reach the temporary files during the update. The directory restriction should be configured carefully by the hosting provider or someone who understands the server setup.

What website owners should do now

• Check your WordPress version: Sign in to the dashboard and open Dashboard → Updates. Check the installed Core version and identify the fixed release for your branch.
• Protect the upgrade directory before the first update: Ask your hosting provider or a qualified WordPress professional to deny public web access to /wp-content/upgrade/ before updating an affected installation.
• Install the appropriate security release: Update to the fixed version for your branch. If you manage the server yourself, follow the researcher’s guidance for carrying out a properly prepared manual update outside the public web root.
• Confirm the update completed: Return to Dashboard → Updates and verify that the site is running the fixed version. Do not assume an automatic update succeeded without checking.
• Review access logs if the site was exposed: Look for unexpected requests to PHP files under the upgrade directory, especially setup-config.php. Pay attention to suspicious requests during update activity.
• Check for signs of an unauthorised change: Review administrator accounts, installed plugins and unexpected PHP files. Investigate anything that cannot be explained by you or another trusted site administrator.
• Get help if you suspect a compromise: Preserve relevant logs and contact your hosting provider or a security professional. Updating the software is essential, but it does not by itself establish that a previously exposed site is clean.

For sites hosted on managed platforms, check the provider’s security and update arrangements rather than assuming that the same manual steps apply to every hosting service.

CVE-2026-119977 is a reminder that even routine maintenance can create a security risk when temporary files become publicly reachable. CISA’s exploitation warning makes prompt action important, but the first update deserves particular attention. Website owners should secure the upgrade directory, install the correct fixed release and check their sites for signs of unexpected activity.