{"id":3914,"date":"2026-11-04T06:48:33","date_gmt":"2026-11-04T14:48:33","guid":{"rendered":"https:\/\/cyber.mag212.com\/cve-2026-119977-wordpress-core-update-race-cisa-kev\/"},"modified":"2026-11-04T06:48:33","modified_gmt":"2026-11-04T14:48:33","slug":"cve-2026-119977-wordpress-core-update-race-cisa-kev","status":"publish","type":"post","link":"https:\/\/cyber.mag212.com\/fr\/cve-2026-119977-wordpress-core-update-race-cisa-kev\/","title":{"rendered":"CVE-2026-119977\u00a0: La vuln\u00e9rabilit\u00e9 de mise \u00e0 jour du noyau WordPress dans CISA KEV, expliqu\u00e9e, avec les versions corrig\u00e9es pour chaque branche"},"content":{"rendered":"

CVE-2026-119977<\/strong> is a race condition in the way WordPress core installs its own updates. For the few seconds a full-package core update runs, a copy of the WordPress installer sits in a predictable, web-reachable folder. An unauthenticated attacker who requests it at the right moment can reach remote code execution. WordPress fixed it in 7.1.4<\/strong> on October 28, 2026, with backports for every branch back to 4.7. On November 3, CISA added it to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation.<\/p>\n\n

This guide explains how the race works, which version fixes your branch, the one web-server rule to add before<\/em> you update, and how to check whether a site was hit.<\/p>\n\n

Key facts<\/h2>\n\n
Item<\/th>Detail<\/th><\/tr><\/thead>
CVE<\/td>CVE-2026-119977 (CWE-367, time-of-check to time-of-use race)<\/td><\/tr>
Affected<\/td>WordPress core 4.7.0 through 7.1.3, every branch<\/td><\/tr>
Fixed<\/td>7.1.4, plus a backport for every branch back to 4.7 (table below)<\/td><\/tr>
Severity<\/td>WordPress rates it Low; Wordfence, the CVE Numbering Authority, scores it CVSS 3.1 8.1 (High, high attack complexity)<\/td><\/tr>
Exploitation<\/td>Listed in CISA KEV on November 3, 2026, with forensic triage flagged<\/td><\/tr>
Federal deadline<\/td>November 6, 2026 (BOD 26-04)<\/td><\/tr>
Login needed?<\/td>No<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

What went wrong<\/h2>\n\n

A full-package core update downloads the new release, unpacks it into a folder under wp-content\/upgrade\/<\/code>, copies the files into place, then cleans up. According to the WordPress advisory, that folder had a predictable name and sat inside the web-served upgrade directory. Patchstack’s analysis adds two details: the folder name came from the package itself, and the cleanup routine deleted the index.php<\/code> that normally stops directory listing.<\/p>\n\n

So for a few seconds a complete WordPress copy, including wp-admin\/setup-config.php<\/code>, was browsable at a guessable path. An attacker who keeps polling that path can hit the installer mid-update and run it against a database the attacker controls, which leads to PHP running as the web-server user.<\/p>\n\n

\"Diagram
The upgrade-window race. Amber marks the vulnerable window; red dashed arrows show the attacker path described in the advisory and research. Timings are illustrative. MAG212 CYBER original diagram.<\/figcaption><\/figure>\n\n

Version 7.1.4 closes the gap three ways: it appends 16 random characters to the staging folder name, keeps index.php<\/code> in place, and never copies wp-config.php<\/code> out of the working directory.<\/p>\n\n

How serious is it in practice?<\/h2>\n\n

The attack needs three things at once: a full-package core update must be running, the staging folder must be reachable over HTTP, and the attacker’s request must land inside a window measured in seconds. That is why the vendor rates it Low and the CNA marks attack complexity as High. But the window reopens on every<\/em> such update, including unattended background updates. Wordfence reported automated polling for the staging path within hours of the release, and CISA now lists it as exploited. Treat it as urgent.<\/p>\n\n

One subtlety matters: the update that installs the fix runs under the old, vulnerable code<\/strong>. That is why researchers advise blocking the staging directory before you update.<\/p>\n\n

Fixed version for every branch<\/h2>\n\n
Branch<\/th>Affected<\/th>Fixed in<\/th><\/tr><\/thead>
7.1<\/td>7.1.0 \u2013 7.1.3<\/td>7.1.4<\/td><\/tr>
7.0<\/td>7.0.0 \u2013 7.0.7<\/td>7.0.8<\/td><\/tr>
6.9<\/td>6.9.0 \u2013 6.9.10<\/td>6.9.11<\/td><\/tr>
6.8<\/td>6.8.0 \u2013 6.8.11<\/td>6.8.12<\/td><\/tr>
6.7<\/td>6.7.0 \u2013 6.7.10<\/td>6.7.11<\/td><\/tr>
6.6<\/td>6.6.0 \u2013 6.6.10<\/td>6.6.11<\/td><\/tr>
6.5<\/td>6.5.0 \u2013 6.5.13<\/td>6.5.14<\/td><\/tr>
6.4<\/td>6.4.0 \u2013 6.4.13<\/td>6.4.14<\/td><\/tr>
6.3<\/td>6.3.0 \u2013 6.3.13<\/td>6.3.14<\/td><\/tr>
6.2<\/td>6.2.0 \u2013 6.2.14<\/td>6.2.15<\/td><\/tr>
6.1<\/td>6.1.0 \u2013 6.1.15<\/td>6.1.16<\/td><\/tr>
6.0<\/td>6.0.0 \u2013 6.0.17<\/td>6.0.18<\/td><\/tr>
5.0 \u2013 5.9<\/td>see advisory<\/td>5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31<\/td><\/tr>
4.7 \u2013 4.9<\/td>see advisory<\/td>4.9.35, 4.8.34, 4.7.39<\/td><\/tr>
4.6 and older<\/td>\u2014<\/td>No fix: migrate<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

Step 1: block the staging folder before you update<\/h2>\n\n

Deny HTTP access to \/wp-content\/upgrade\/<\/code> at the web server or CDN. WordPress writes to this folder through the filesystem, not over HTTP, so updates keep working. A security plugin running inside PHP will not stop this attack: Patchstack notes the staged copy loads its own files, so the site’s PHP firewall never runs for that request.<\/p>\n\n

# NGINX: inside the site's server { } block\nlocation ^~ \/wp-content\/upgrade\/ {\n    deny all;\n}\nsudo nginx -t && sudo systemctl reload nginx\n\n# Apache 2.4: in the VirtualHost (not a file inside upgrade\/)\n<Directory \"SITE_DOCROOT\/wp-content\/upgrade\">\n    Require all denied\n<\/Directory>\nsudo apachectl configtest && sudo systemctl reload apache2<\/code><\/pre>\n\n
Put the Apache rule in the virtual host, not in an .htaccess<\/code> inside the upgrade folder: before 7.1.4, cleanup deleted files there. Replace SITE_DOCROOT<\/code> with your document root, and adjust the path if WordPress lives in a subdirectory. On managed hosting, ask your host to confirm the block at its web or CDN layer.<\/p>\n\n
Step 2: update and verify<\/h2>\n\n
Install 7.1.4 or your branch’s fixed release, then confirm with WP-CLI (run as the site’s system user from the WordPress root):<\/p>\n\n
wp core version                       # expect the fixed release for your branch\nwp core verify-checksums              # compares core files with WordPress.org\nwp user list --role=administrator --fields=ID,user_login,user_registered\nfind wp-content\/upgrade -mindepth 1 -maxdepth 3 -ls   # normally only index.php\ncurl -sI https:\/\/SITE\/wp-content\/upgrade\/              # expect 403<\/code><\/pre>\n\n
How to tell whether a site was hit<\/h2>\n\n