Hackers are actively exploiting a flaw in WordPress itself that strikes at the worst possible moment: during a core update. The vulnerability, tracked as CVE-2026-119977, is a race condition in the WordPress core updater that lets an unauthenticated attacker run code on a site's server. It carries a severity score of 8.1 out of 10, and on 3 November 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalogue, confirming it is being attacked in the wild. Federal civilian agencies were given until 6 November to patch.

How the attack works

When WordPress installs a full core update, it first unpacks the new files into a temporary folder with a predictable name, wp-content/upgrade. That folder can be reached from the web, and the copy includes the WordPress installer. During the few seconds the update is unpacked, an attacker who calls the installer can restart the installation process, point the site at a database they control and run code on the server.

As the researcher who found the flaw explains, the attacker wins a race between the extraction of the update and the copying of its files. By placing a malicious wp-config.php file in the temporary folder, the attacker can have the updater copy it over the site's live configuration. The replacement file redirects the site to an attacker-controlled empty database, which exposes the WordPress installation workflow. The attacker can then create the first administrator account and, on a typical single-site installation, upload a malicious plugin to execute arbitrary PHP code.

Who found it and what is affected

The flaw was discovered by Umut Bayram of Picus Security, and independently analysed by researchers at Xint. It affects WordPress versions 4.7 through 7.1.3. WordPress fixed it in version 7.1.4, released on 28 October 2026, with security releases backported to every maintained branch down to 4.7. Versions 2.7 through 4.6 did not receive a fix and should be upgraded to a supported version.

Attacks began within minutes

Exploitation attempts started almost as soon as the flaw became public. Wordfence, the security firm that assigned the CVE identifier, says the first attempt arrived nine minutes after its firewall rule went live, and it recorded more than 18,500 malicious requests aimed at the staging installer paths in the first 21 hours. By 5 November, Wordfence says its firewall had blocked more than 240,000 exploit attempts, peaking at over 74,000 in a single day on 30 October.

No site has been publicly confirmed as compromised through the flaw so far. Hitting a window that lasts only seconds is hard, and most attempts fail, but sites that update often, or whose updates stall part-way through, give attackers more chances to land the timing.

What to do now

Because the attack targets the update itself, the order of the fix matters. Site owners should first block web access to the wp-content/upgrade folder at the server level — WordPress never needs that folder served to visitors — and only then run the update to 7.1.4, or to the security release for their branch. The version a site runs is shown at the bottom of the WordPress dashboard and under Dashboard > Updates.

After updating, owners should check for anything unexpected, such as administrator accounts they did not create or unfamiliar plugins. The flaw sits in WordPress core rather than in a plugin or theme, so it affects any site on an affected version, whatever else is installed. With CISA listing it as actively exploited and hundreds of thousands of attempts already recorded, updating is not a job to leave for later.