Skip to content
ITLAB
ESEN

04 / 11 / 2026 · Cybersecurity and regulation

WordPress: the flaw that opens during an update

CVE-2026-119977 is exploited while WordPress updates itself. Which version to install, how to update without exposure, and what to check afterwards.

The usual advice is to update. It's still right this time, with one catch: this flaw is exploited during the WordPress core update itself. You should update now, and it's worth closing off one folder first. Public status as of November 4, 2026.

What happened

The flaw is tracked as CVE-2026-119977 and affects WordPress core. The US cybersecurity agency (CISA) added it on November 3 to its catalog of exploited vulnerabilities, giving federal agencies until November 6 to act. That confirms real attacks, although neither CISA nor the sources we reviewed name any compromised sites.

  • How it works. During a full update, WordPress briefly leaves installer files in predictable, internet-accessible paths. Anyone who reaches them at that moment can run code on the server with no username or password, according to Qualys and the analysis by Umut Bayram of Picus Security, who reported it.
  • Severity. CVSS 8.1, according to Rapid7. It doesn't score higher because the attack is hard to pull off: it has to hit a very brief moment. SOC Prime says the window may last only seconds.
  • Attack attempts. Wordfence logged more than 18,500 requests to those paths in the first 21 hours, according to Qualys and SOC Prime. Counts of attempts blocked in 24 hours vary by who cites them: 12,632 in Qualys, 13,095 in BleepingComputer and nearly 59,000 in GBHackers, cited by SOC Prime. These are attempts, not compromised sites.

Which version to install

The fix arrived with WordPress 7.1.4, released on October 28.

Installed branchFixed version
7.17.1.4
7.07.0.8
6.96.9.11
6.86.8.12
Older branches, back to 4.7Each has its own fixed version (for example, 4.7.39)
4.6 or earlierNo fix: you need to migrate

The table follows the lists from Qualys and Safeguard. If your site is on an old branch, the better move is to bring it to a current version, not just its latest patch.

Why waiting for the automatic update isn't enough

According to Safeguard, every core update opens that window, whether it runs from the dashboard or in the background. And both Safeguard and Picus hold that the update to 7.1.4 itself goes through the window one last time. Safeguard makes clear this is its reading of the code, not a statement from the WordPress project.

The risk of that moment is limited, and staying unpatched is worse. But this time the order matters.

How to update

  1. Back up files and database, and confirm the backup can be restored.
  2. Block web access to `wp-content/upgrade/` in the server configuration. Picus provides the rules for nginx and Apache, and warns that the `.htaccess` file must not go inside that folder. Check that a request to that path returns a 403 error.
  3. Update to the fixed version for your branch.
  4. Confirm in the dashboard that the right version is installed and that the site works.
  5. Leave the block in place. Safeguard recommends keeping it, and testing the rule on a staging site first if you have one.

A web application firewall (WAF) helps, but SOC Prime warns that it doesn't replace the patch and that you should check it really inspects direct requests to those files. If your site is on managed hosting with no access to the configuration, ask your provider whether they've already applied the block and the update.

What to check afterwards

CISA published no indicators of compromise. Based on how the flaw works, Safeguard and SOC Prime suggest looking for:

  • Requests to `/wp-content/upgrade/` in the server logs, especially successful responses to `setup-config.php` or `install.php`.
  • PHP files in `wp-content/upgrade/` or in the uploads folder.
  • Unexpected changes to `wp-config.php`.
  • New administrator accounts.

The review should go back at least to October 30, the date of the earliest attempts SOC Prime reports. If you find any of these signs, don't just update: treat the site as compromised, keep the logs, restore from a clean backup and change passwords and keys.

While you're at it: check your plugins

This week also brought reports of attack attempts against CryptoPayment Gateway, a crypto payments plugin already removed from the official directory, according to The Hacker News. The flaw, CVE-2026-81648, has a CVSS of 10 and affects versions 1.2.1 and 1.2.2, according to OpenCVE, and has no fix. If you use it, uninstall it, change the wallet keys and review recent changes.

It's a good moment to review all your plugins: the ones that no longer get updates won't get the next patch either.

Frequently asked questions

Should I update even though updating is the moment of risk? Yes. The window is very brief, and staying on an unfixed version carries the problem into every future update. The recommended order is to block the folder first and then update.

My site already updated itself. Am I safe? On a fixed version the flaw can no longer be exploited in future updates, but that doesn't rule out that it happened earlier. It's worth running the checks above.

How much time do I have? Attacks are already under way. The November 6 deadline applies to US federal agencies, but it's a useful reference: this gets solved in days, not weeks.

Does a WAF protect me? It helps, but it doesn't replace the patch.

What if I'm on version 4.6 or earlier? There's no fix. You need to migrate to a supported version.

Sources

Contact

If you need to update or review your organization's WordPress site, ITLab can help. Contact us.

Do you need someone to take care of your technology?

Tell us what you need to organize, protect or solve. The first conversation has no cost: we assess whether our model fits you and what the next steps would be.

Let's talk about your business