On November 3, 2026, CISA added a vulnerability in the WordPress core to its catalog of exploited vulnerabilities. All versions from 4.7 to 7.1.3 are affected. For US federal agencies, November 6 is the deadline; for all other operators, the entry remains a warning without any obligation.
WordPress released the security release 7.1.4 on October 28, 2026 and advises updating immediately. The release also fixes several cases of stored cross-site scripting (XSS), including through crafted block markup.
How does the attack work during the update?
During a core update with a full package, WordPress unpacks the new files to a predictable location that the web server serves. If an unauthenticated attacker wins the race against the unpacking, they can execute code on the server within this time window. Experts call this a race condition (CWE-367).
Wordfence assigned the identifier CVE-2026-119977 and rates the flaw at 8.1 out of 10 points, i.e. high, with high attack complexity. In its announcement, WordPress describes the flaw as a vulnerability in the upgrade process that could enable remote code execution during the update window, and omits the identifier and score.
Attack attempts are already underway. According to XHack, Wordfence counted more than 18,500 requests to the installation paths in the first 21 hours after activating a firewall rule. Wordfence has reportedly not reported a successful attack so far.
Which version fixes the flaw?
Each version series has its own fixed version. The information comes from XHack, as of November 4, 2026:
Version series
Fixed in
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
XHack also lists fixes for older version series down to 4.7, the latest being 4.7.39; according to XHack, no more security updates are being released for 4.6 and older. WordPress itself wrote on October 28 that the fixes for older version series would be released gradually.
How do you update safely?
The order is crucial, because the update process is still carried out by the old, vulnerable code. According to XHack, Patchstack therefore advises blocking web access to wp-content/upgrade before the update, in the server configuration or via the host. A security plugin, by contrast, only protects the running site, not the temporary copy of the new files.
How to update in four steps
Sequence for WordPress sites running a version up to 7.1.3, according to Patchstack and XHack
Backupfull backup of files and database
Blockblock web access to wp-content/upgrade in the server
Updateupdate to 7.1.4 or the fixed version of your version series
Checkverify the installed version, secure logs if you suspect an attack
Test the server configuration before use
Sources: WordPress.org, XHack, CISA
According to the release post, WordPress updates sites with automatic background updates enabled by itself. Check there as well whether 7.1.4 or the fixed version of your version series is actually installed.
What this means for you
Go through all the WordPress installations you manage today:
Open the Updates section in the dashboard and compare the version with the table. If the version is below the fixed version of your version series, it is best to update immediately.
Have a backup created before the update and block web access to wp-content/upgrade. With managed hosting, check with the host whether they have already done this.
If you suspect attacks, secure the server logs first before you clean up. Afterwards, check administrator accounts, plugins, and files.
If you manage client sites, a short message to the clients is worthwhile: An update with a backup and a blocked folder this week is easier to explain than an incident.
CISA added the vulnerability to the catalog on November 3, 2026.
