Vulnerability · CVE-2026-119977
The WordPress fix is unpacked by the old code.
CISA added this on 3 November 2026. The federal due date was 6 November. The triage flag is set. The awkward part is that installing the fix can open the window once more.
Class
WordPress core, during a full-package upgrade, unpacks the new tree into a temporary directory under the upgrade folder and can reach an installer from the web. CISA's catalog text calls it a time-of-check/time-of-use race: an unauthenticated attacker who hits that window can run code on the server. Public reporting, including WordPress's own security note, puts the affected line at 4.7 through 7.1.3.
This note stops there. The temporary name, the installer action, and the file the race has been used to replace are published elsewhere. Copying them here does not help the person who has to ship 7.1.4 tonight.
The release that fixes it
WordPress 7.1.4 shipped on 28 October 2026. The project describes one of the fixes as a race during core updates that can lead to remote code execution, credited to Umut Bayram. The same advisory says older branches got their own packages: 7.0.8 for the 7.0 line, 6.9.11 for 6.9, 6.8.12 for 6.8, and further branch releases on the version page. A 6.8 site is not "done" because someone read the number 7.1.4. Match the branch.
Why the update is part of the bug
Reporters have said the package that contains the fix is still unpacked by the unpatched code already on the site. On the way to a fixed install, the window exists one more time. The practical instruction attached to that warning is to deny web access to wp-content/upgrade/ before you run the update, then confirm the version after. That is a patching step. It is not a map of the race.
Do this on a host you can roll back. Automatic updates that fire while the directory is still web-reachable are the case this note is about, not a lab demo.
Triage, because the due date already passed
CISA marked forensic triage. A site that only shows 7.1.4 today can still have been hit on the way there, or in the weeks the bug was public before the catalog entry. Look for things the site did not deploy:
- PHP files in the web root or uploads with timestamps on the upgrade, and owners you did not assign.
- Administrator accounts created on the same dates.
- Outbound connections from the web-server user that the host does not make on a normal day.
If an upgrade was left half-applied and nobody can say what the temporary tree contained, the decision is rebuild-or-not, not a version bump alone. This page will not name a webshell or a request.
Who can close the ticket
You run WordPress, the branch build from the 28 October advisory is installed, the upgrade directory was not web-reachable during that install, and someone looked at the three checks above for the window between public disclosure and the patch. If you do not run WordPress, close the row.