What happened
When WordPress installs a full core update, it unpacks the new files into a staging location before swapping them in. The NVD entry for CVE-2026-119977 says those staging paths were “predictable, web-accessible,” which “makes it possible for unauthenticated attackers to execute code on the server during the upgrade window.” In plain terms: for the short time a site is upgrading itself, a stranger who knows where to look can get code onto it.
WordPress’s own release post for 7.1.4 describes the fix as a remote code execution weakness in the upgrade process that “can lead to remote code execution during the upgrade window,” and credits Umut Bayram for the report. The same release fixes twelve other issues, most of them stored cross-site scripting in blocks and the Customizer, and updates the bundled root certificates.
On November 3, CISA added the flaw to its Known Exploited Vulnerabilities catalog, which it reserves for flaws it has evidence are being used against real systems, and gave federal agencies three days to deal with it.
Who is exposed
- Every WordPress site from 4.7 up to 7.1.3, which is nearly every WordPress site that exists. The weakness is in core, not a plugin or theme.
- The dangerous moment is while a core upgrade runs. A site that is simply sitting on an old version is not being attacked through this at rest; it is attacked when it updates, and sites do update, often automatically and often at predictable times.
- WordPress says the fixes are being backported to every branch still eligible for security fixes, back to 4.7, and that the backports “will ship as they become ready.” A site stuck on an old branch may not have its fix yet.
- Sites with automatic background updates on will have moved to 7.1.4 on their own. That is the right outcome, and it also means they went through one more upgrade window on the old updater to get there.
What to do
- Read the versionDashboard, bottom right corner, or Dashboard > Updates. You want 7.1.4 or later. Our free website check reads it from outside too.
- Update if you are not thereDashboard > Updates > Update Now, or let your host do it. After this one update, the updater itself is fixed, so future upgrades close the window.
- Check that automatic updates are onMost managed hosts handle minor security releases for you. If a site is still on 7.1.3 or earlier two weeks after October 28, something is switched off or broken. Ask.
- If the site cannot move past an old branchSome sites are pinned to 5.x or 6.x by an old theme or plugin. Ask the host whether the backport for that branch has shipped; if it has not, plan the move to a supported version rather than waiting.
- Have the site scannedIf a site upgraded itself between October 28 and the day you read this, run a malware scan after the update. Any new PHP file you did not put in wp-admin, wp-includes or the uploads folder is a reason to call someone.
The fix is in the updater, so a site is only safe after it has updated to 7.1.4 once. Do it on purpose, today, rather than leaving it to the schedule.
This is the second exploited flaw in WordPress core this fall; the earlier one needed the September 22 update. Our vulnerability database tracks every WordPress core, plugin and theme flaw as it is published. If you think a site was entered during an upgrade, incident response is the page to start from.
Sources
Written by Nikita Huttenlocher, founder and lead engineer at Huttenlocher Technologies, a cybersecurity and software firm in Myrtle Beach, South Carolina. This is general guidance, not a review of your systems.
Weekly security brief
The flaws that hit local websites, every Friday.
One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.