WordPress 7.1.4 Fixed Remote Code Execution During the Upgrade Window. Ten Days Later, Check That Your Sites Actually Updated.
WordPress 7.1.4 shipped on October 28, and the release post describes one security fix in plain terms: a weakness in the upgrade process that can lead to remote code execution during the upgrade window. That is a strange kind of bug. The risk is not that your site sits vulnerable all day. It is that your site is exposed for a short stretch every time it updates, which means the sites most at risk are the ones that update most often and are watched least.
What the release post confirms
The post, written by Aaron Jorbin, credits Umut Bayram with the report. It says the fixes were backported to all branches eligible for security fixes, currently going back to 4.7, but also that the backports "are in progress" and will ship as they become ready. So "I am on a supported branch" does not automatically mean "I have the patch yet."
It also says sites that support automatic background updates will start the update on their own. What it does not say is that every site will get through it cleanly or on a given day.
What I could not confirm
A security news site published a longer write-up on November 5 that names a CVE number, says the flaw involves predictable staging content under wp-content/upgrade that is reachable from the web, and says the issue was added to CISA's Known Exploited Vulnerabilities catalog with a federal due date of November 6. It also cites a security vendor for a large count of probing requests in the first day.
I could not verify any of that against a primary source. The WordPress post names no CVE, no CVSS score and no affected-version range, and the CISA page would not load for me. I would treat "this is being exploited" as plausible and unproven. It does not change what you should do, because the fix is the same either way.
The ten-minute check
If you run more than one WordPress site, even as a side income from clients, do this now:
- List every site and the version it reports. In the dashboard that is Dashboard, then Updates. From a shell with WP-CLI,
wp core versionper site does it. - Compare against your branch's latest release, not just 7.1.4. If you are on an older branch, check that its backport has actually shipped.
- Look in the web server access log for requests to paths containing
wp-content/upgradebetween October 28 and today. Normal visitors have no reason to request them. - Confirm automatic updates are not silently failing. A failed update leaves a site on the old version with no loud error.
- Update by hand any site that is behind, then take a backup first.
Step 3 is a hint, not a verdict. An empty log does not prove a clean site, and a hit does not prove compromise. If you do find hits followed by unexpected new PHP files, treat the site as compromised and restore from a backup taken before October 28.
Where I could be wrong
Maybe this is a tiny window that is hard to hit. Maybe your hosting provider already patched at the platform level, and managed hosts often do. In that case you will find the version already current and have spent ten minutes confirming it. That is a cheap price for knowing.
What I'd actually do
Write the site list into a single note with the version and the date you last confirmed it, and re-check after every core security release. The reason this class of bug hurts solo operators is not skill, it is inventory. You cannot patch a site you forgot you hosted.
Author
Lukas
@lukcombinator