CVE-2026-119977 lets an attacker without an account execute code on the server during a WordPress core update. Fixed in 7.1.4 and down to 4.7, it has been in CISA’s exploited catalog since 3 November. What to check, why the last update matters and when to notify the FDPIC.
On 28 October 2026 WordPress released security version 7.1.4, with fixes backported to every earlier branch down to 4.7. The most important one concerns CVE-2026-119977: during a core update, an attacker without any account who strikes at the right moment can end up executing code on the server. On 3 November the US agency CISA added the flaw to its Known Exploited Vulnerabilities catalog (KEV), based on evidence of active exploitation.
For a Ticino SME with a WordPress site the practical consequence is simple: the site must run the fixed version, and it is worth checking that nothing unusual has happened since 28 October. One detail makes this case different from the usual one, though: the flaw sits in the update process itself.
What happened
According to the WordPress security advisory (GHSA-4w3m-c66w-69mg, 29 October 2026), during a core update using a complete package WordPress extracted the new files to a predictably named folder inside wp-content/upgrade, which is reachable from the web. Whoever wins the race against that extraction, in the few moments the temporary copy exists, can reach code execution. Versions 4.7 to 7.1.3 are affected.
The severity ratings differ, and it helps to understand why:
- WordPress rates the flaw as low severity, because the usable window is very short.
- Wordfence, which assigned the CVE, gives it a CVSS 3.1 score of 8.1 (high), as listed in the NVD database: attack complexity is high, but if the attack succeeds the impact on the server is total.
- CISA considers it actively exploited, and the Canadian Centre for Cyber Security issued an advisory on 3 November.
According to Wordfence, the first attempts started on the day of disclosure and its firewall has blocked more than 240,000 of them. Wordfence notes that succeeding is difficult in practice: repeated automated attempts are aimed precisely at catching the brief update moment.
The detail to know: the last update
The fix randomises the name of the temporary folder. But the update that installs 7.1.4 is still run by the old code already on the site: according to Wordfence, moving from the vulnerable version to the fixed one therefore opens the window one last time, for the duration of the update. After that, future updates are no longer affected.
This is not a reason to postpone: Wordfence recommends updating as soon as possible. As an additional precaution, it suggests blocking access to PHP files in the /wp-content/upgrade/ folder at web server level before updating. WordPress writes to that folder directly on the file system, so blocking web access does not prevent the update.
Fixed versions
Versions listed as fixed in the WordPress advisory (excerpt; the full list covers every branch down to 4.7):
| Branch | Fixed version |
|---|---|
| 7.1 | 7.1.4 |
| 7.0 | 7.0.8 |
| 6.9 | 6.9.11 |
| 6.8 | 6.8.12 |
| 6.7 | 6.7.11 |
| 6.6 | 6.6.11 |
| 6.5 | 6.5.14 |
| 6.4 | 6.4.14 |
| 6.3 to 4.7 | latest release of the branch (for example 4.7.39) |
WordPress points out that only the most recent version is actively supported: anyone still on an old branch should plan the move to 7.1.
What to do with your WordPress site
- Check the version. In the dashboard under Updates, or by asking your provider. It must show 7.1.4 or the fixed release of your branch. Automatic background updates have normally installed it already, but check: they do not always succeed.
- If the site is not yet updated: back up files and database, ask whoever runs the server to block web access to PHP files in
/wp-content/upgrade/, and update right away. - Look for signs of compromise since 28 October. In the server access logs, successful requests to
/wp-content/upgrade/; in the dashboard, unknown administrator accounts; on the server, unexpected PHP files or unplanned changes towp-config.php. For its own agencies, CISA requires a forensic check for precisely this flaw. - If you find indicators: treat the site as compromised, isolate it, change credentials (administrators, database, API keys), restore from a clean backup taken before 28 October and have the server analysed. Updating alone does not remove anything an attacker may already have installed.
- Plugins, themes and PHP. Use the opportunity to update plugins and themes too and to check the PHP version: in October critical PHP flaws and several WordPress plugins were also fixed.
We do not publish details on how to exploit the flaw: the goal is to close exposure and check systems.
If the site was compromised: reporting
- Data protection (FADP). If the site or server holds personal data (contact forms, customer accounts, orders) and the breach is likely to result in a high risk for the people concerned, article 24 of the Federal Act on Data Protection requires notifying the FDPIC as soon as possible. The FDPIC guidelines explain how to assess and report the case.
- NCSC. For most SMEs reporting a cyber incident to the National Cyber Security Centre (NCSC) is voluntary but useful. Since 1 April 2025, operators of critical infrastructure have a reporting obligation for cyberattacks within 24 hours of discovery.
- Financial damage. If you suffer a loss, file a complaint with the cantonal police.
Frequently asked questions
Our site updates itself: do we need to do anything?
According to Wordfence, sites with automatic updates enabled should already be on a fixed version. It is still worth checking the installed version and reviewing the logs since 28 October, because the last update went through the old code.
Why does WordPress rate it low while CISA lists it as exploited?
The two assessments look at different things: WordPress weighs how hard it is to hit the brief update window, CISA the presence of real exploitation attempts. For site owners the conclusion is the same: update and verify.
Our site is managed by an agency: what should we ask?
Three questions are enough: which WordPress version is installed, whether web access to /wp-content/upgrade/ is blocked, and whether the logs since 28 October have been checked. Ask for a written answer.
We have a firewall or a security plugin: are we protected?
Not necessarily. Wordfence explains that the attack targets files that do not load WordPress, so a security plugin running inside the site only sees them in specific configurations. Blocking at web server level and updating remain the main measures.
Our approach
ElaraTeq Sagl helps SMEs and practices in Ticino update and review WordPress sites, configure web servers and host in Switzerland (hosting, consulting). To have your site checked you can contact us.
Sources
- WordPress, WordPress 7.1.4, 28 October 2026
- WordPress, GHSA-4w3m-c66w-69mg: A race condition during core updates that could lead to remote code execution, 29 October 2026
- NIST NVD, CVE-2026-119977
- CISA, CISA Adds One Known Exploited Vulnerability to Catalog, 3 November 2026
- Canadian Centre for Cyber Security, WordPress security advisory (AV26-1117), 3 November 2026
- Wordfence, Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core, November 2026
- NCSC, Reporting obligation for cyberattacks on critical infrastructure
- FDPIC, Guidelines on data breaches