What happened
In late October 2026, the WordPress project released security update WordPress 7.1.4. It fixes several issues, the most serious being a weakness in the core upgrade process that, according to WordPress, can lead to remote code execution during the upgrade window. It was reported by researcher Umut Bayram. The flaw is tracked as CVE-2026-119977, and as EUVD-2026-114575 in the European EUVD database.
Security company Wordfence said an attacker does not need an account on the site to exploit it. They do, however, have to hit a brief window while a full WordPress core update is running. According to The Hacker News, Wordfence recorded more than 18,500 requests targeting the flaw in the first 21 hours after disclosure and blocked 12,632 attack attempts within 24 hours.
On November 3, 2026, the US agency CISA added the flaw to its KEV catalog of actively exploited vulnerabilities. The EU agency ENISA’s EUVD database has also listed it as exploited since the same day. According to The Hacker News, the company Previdian observed three exploitation attempts against its honeypot sensors as early as October 30, 2026.
Why it is dangerous
This is a race condition of the TOCTOU type, short for “time of check, time of use”. During a full update, WordPress temporarily stages the new package files in a location that is predictable and reachable from the web. That creates a short gap that an attacker can use to run their own code without logging in.
Think of an office move: during the move, boxes sit in the hallway next to an open door. Most of the time nothing happens, but anyone who knows when and where the boxes will be can take something or slip something in.
The attack works over the internet and needs no login and no action by a user. The catch is that it has to land during the update window. If it succeeds, the attacker can run their own code on the server. The CVSS rating assumes a high impact on confidentiality, integrity and availability. In practice, that can mean data stolen from the site, changes to the site or planted malware.
The CVSS severity score, on a scale from 0 to 10, is 8.1, which is high. It was assigned by Wordfence using CVSS 3.1. The main reason it is not higher is that the attack depends on precise timing.
The CISA KEV catalog lists flaws for which the US government has evidence of real-world attacks. US federal agencies must fix this one by November 6, 2026. CISA has not stated whether ransomware groups are using it.
EPSS is a statistical estimate of the likelihood of exploitation over the next 30 days. As of November 3, 2026, it stood at 0.6%, higher than roughly 49% of scored vulnerabilities. Confirmed attacks outweigh this estimate, so do not let the low number reassure you.
Who is affected
All WordPress installations from version 4.7 through 7.1.3 are affected. The fix is included in WordPress 7.1.4 and in the 7.2 Beta 3 test release.
Typical targets are company websites, blogs, WooCommerce shops and organisation sites running on shared web hosting, a dedicated server or a VPS. The risk is tied to the moment a full core update is running.
Sites built on other content management systems are not affected. The vulnerability description does not list versions older than 4.7 as affected. However, those no longer receive security fixes, so treat them as risky anyway.
How to check if you are affected
In the WordPress admin, go to Dashboard → Updates, which shows your current version. It also appears in the bottom right corner of the admin footer. If you have SSH access to the server, use the commands below, which only read information.
wp core version --path=/var/www/htmlWithout WP-CLI, you can read the version from the file wp-includes/version.php. In both commands, adjust /var/www/html to where your site lives.
grep -F '$wp_version =' /var/www/html/wp-includes/version.phpIf the server hosts several sites, check each one separately. Version 7.1.4 or later is safe, as is a fixed release of an older branch once WordPress publishes it.
How to fix it
WordPress recommends updating immediately. The fixed version is WordPress 7.1.4. Fixes for older branches back to 4.7 are being prepared and released gradually, and WordPress has not yet listed their version numbers. Only the most recent version is actively supported.
- Back up the site files and the database, and confirm the backup can be restored.
- Update via Dashboard → Updates → Update Now, or on the server with
wp core update. - After updating, confirm the version with
wp core versionor in the admin. - If automatic background updates are enabled, check that the site is actually running 7.1.4.
- If you are on an older branch such as 6.x, ideally move to 7.1.4. If plugins prevent that right now, watch for the fix for your branch.
WordPress does not list a separate workaround. The update is the fix. Because the flaw is tied to the update process itself, run the update as soon as possible and watch it complete rather than postponing it. A web application firewall from your host or a security plugin can also help: according to The Hacker News, Wordfence blocked thousands of such attempts.
Work in this order: online shops and sites holding personal data first, everything else after. Then immediately run the checks in the next section. Version 7.1.4 also fixes several XSS flaws, so it is worth installing regardless of this issue.
What if you may already be compromised
According to The Hacker News, Previdian saw the first attack attempts as early as October 30, 2026. If you ran a full core update on a vulnerable version since then, check the site.
- Search the web server access logs for requests to
setup-config.phpin unusual paths, especially around the time of an update. According to Wordfence, these are what the attacks targeted. - Unknown administrator accounts, which you can list with
wp user list --role=administrator. - Modified or unexpected core files, which
wp core verify-checksumswill flag. Look for new PHP files mainly inwp-content/uploadsandwp-content/upgrade, and watch for unfamiliar plugins or themes. - Changes to
wp-config.php, unexpected redirects or spam on the site.
zgrep -i 'setup-config\.php' /var/log/apache2/access.log* /var/log/nginx/access.log* /var/log/httpd/access_log* 2>/dev/null
wp core verify-checksums --path=/var/www/html
find /var/www/html/wp-content/uploads /var/www/html/wp-content/upgrade -name '*.php' -newermt '2026-10-30' -ls 2>/dev/nullAdjust the log and site paths to match your server. Do not run find across the whole site directory, because after an update every core file is new. If you find anything, do not rush to clean it up yourself. Put the site into maintenance mode, preserve the logs and bring in an incident response specialist. If the attacker could have seen personal data, GDPR may require you to notify the data protection authority within 72 hours. After cleanup, change all passwords, including the database password, and the keys in wp-config.php.