The WordPress security team describes the flaw as a weakness in the upgrade process which can lead to remote code execution during the upgrade window. It is a race condition: while a full core upgrade is running, an unauthenticated attacker who can reach the temporary files the upgrade creates may be able to run code on the server. It is not an easy attack, but it is being used. Wordfence reported blocking more than 13,000 attempts against it in a single day.
WordPress 7.1.4 fixed it alongside twelve other issues, most of them stored cross-site scripting in blocks, the Customizer and the Interactivity API. The fixes have been backported to older branches that still receive security releases, though the project only actively supports the latest version.
Why this one catches organisations out
Most WordPress sites take minor security releases automatically. Larger ones often do not, and for understandable reasons: automatic updates are switched off so changes can be tested first, code is deployed from a repository rather than updated in the admin, or the site sits on hosting where nobody is quite sure who owns updates. Those are the sites that are still on 7.1.3, and the flaw sits in exactly the process they have chosen to manage by hand.
Switching off automatic updates is a sound decision only if someone is doing the updates instead.
- Which WordPress version every site you run is on, including microsites, campaign sites and staging
- Whether minor security releases install automatically, and if not, who applies them and how fast
- Whether a security release can get from announcement to production in a day, including testing
- Whether your firewall or host is blocking attempts against this flaw in the meantime
- Whether anything unexpected has appeared in the WordPress directories since 28 October
Patching is a process, not a plugin
An enterprise WordPress build should make a security release boring. That means a known list of what is installed, a deployment pipeline that can ship core updates in hours rather than in the next sprint, automated checks that tell you the site still works afterwards, and a named owner. If a release this serious would take your organisation a week, that is worth fixing before the next one, not just this time.
If you need WordPress sites patched and monitored today, our sister company WebsiteSupport.io covers WordPress support and maintenance. Reviewing how your sites are built and deployed, so the next release is routine, is what we do here.
