WordPress Auto Updates Are Not a Security Strategy

For most of the last decade, the WordPress security community's default advice on updates was straightforward. Turn on auto updates for core, turn on auto updates for plugins, and get out of the way. The reasoning was reasonable. Most compromises come from outdated software. Most people don't apply updates promptly. Automating the process eliminates the human bottleneck. All correct, all still broadly true.

But 2026 has quietly finished the argument for auto updates as a complete strategy. Two separate incidents this year, one at the core level and one at the plugin level, have shown that the update pipeline itself is now the attack surface. If you're using auto updates as your security layer rather than one component of a wider approach, you are one bad release away from a bad day.

This post is about what those incidents were, why they matter for the way you keep sites updated, and the workflow that's replacing "turn it all on and forget it".

The two incidents worth understanding

WordPress 6.9.2, released 10 March 2026

A routine security release that patched ten issues. Within hours of the auto update rolling out, sites running themes with a certain uncommon PHP pattern (non-standard "stringable objects" in template loading) began crashing. WordPress shipped 6.9.3 the same day to fix the crash. On 11 March, 6.9.4 landed because three of the original patches, including a Notes authorization bypass and an XXE in the bundled getID3 library, hadn't fully applied. Two more updates arrived on production sites, still automatically, still without staging tests, still in less than 48 hours.

For most sites, everything was fine. For sites running the affected theme pattern, auto updates took them down. For everyone, the episode made a specific point that hadn't landed for the wider community: the auto update pipeline treats a rushed emergency patch and a considered scheduled release identically. It applies both immediately.

ShapedPlugin's build pipeline was compromised on 21 May 2026

The attacker didn't hit the WordPress sites directly. They hit the developer's build system, then let the developer publish the compromised code as an official Pro release through the normal update channel. Sites running Product Slider Pro for WooCommerce, Real Testimonials Pro, or Smart Post Show Pro that took the update in the following weeks had a webshell installed in a hidden folder, admin accounts created with names like developer_api1, and a login bypass planted. CVE-2026-10735, CVSS 9.8. The affected sites were up to date. They had been up to date the moment the compromised release shipped. Auto updates delivered the payload on time.

There was also the EssentialPlugin backdoor in April, where a plugin portfolio changed hands and the new owner planted a backdoor. Same pattern. The update channel was trusted. The trust was misplaced.

Three incidents, three different attack shapes, one common thread. When the trusted channel is the delivery mechanism, the auto updater is not on your side any more.

What auto updates are actually good at

Nothing above changes what auto updates do well, which is important because the response is not to switch them off. Auto updates handle the case that used to compromise the majority of WordPress sites and probably still does: a plugin with a known CVE, a patch that shipped weeks ago, and a site owner who never installed the update. That failure mode is real, it accounts for enormous amounts of WordPress compromises every year, and auto updates fix it completely.

The point is not that auto updates are bad. The point is that they solve one specific class of problem, and the community spent a decade acting as if they solved all of them.

The workflow that replaces "auto everything"

Nobody in the WordPress security community is calling for auto updates to be turned off wholesale. What has shifted is the recommended shape of the workflow. The consensus in mid 2026 looks roughly like this.

Core auto updates: stay on, but with staging on any site that matters - WordPress core is unusual in that a serious core release affects tens of millions of sites at once, community feedback surfaces very quickly, and if you delay 24 to 48 hours you are almost certainly waiting for a bugfix release that will follow. On a site that generates revenue or hosts anything you can't afford to lose, run core auto updates on a staging environment first with a 24 to 48 hour observation window before the same version reaches production.
Plugin auto updates: on for uncontroversial plugins, delayed 24 to 48 hours for anything with real reach into your site - WordPress.org itself started imposing a 24 hour cooldown on plugin updates in 2026 for exactly this reason. Community detection of a compromised release now typically happens in the first day. If your update workflow gives that day time to run, you're catching the compromises that would otherwise reach you through the trusted channel.
Emergency and forced updates: read the advisory before you trust the fix - WordPress core forced 6.9.4 out over 6.9.2 because 6.9.2's patches hadn't fully applied. The Plugin Review Team force pushed a cleanup version of the EssentialPlugin portfolio in April. Both were correct actions and both were incomplete. In neither case did the forced update remove attacker artefacts that had already been written to the file system. Auto updates work forward. They don't work backwards.
Pair auto updates with file integrity monitoring - This is the specific check the auto updater cannot do. If an attacker's payload has written a file into your web root, or added lines to wp-config.php, a signature based scanner won't notice and an auto update won't touch it. File integrity monitoring will. On a self managed setup, AIDE or Tripwire are the classic tools. On WordPress specifically, Wordfence's scanning module covers most of it if you're already running Wordfence.
Know what you have installed and who owns it - The specific thing that made both the EssentialPlugin and ShapedPlugin cases work is that install counts and last updated dates don't tell you who currently controls the codebase. A plugin you installed in 2021 from a developer you trusted may in 2026 be run by someone else entirely. Keeping a running inventory of what's on your sites, and being suspicious when a stable plugin suddenly ships a new build, is now table stakes.

What this doesn't mean

It doesn't mean auto updates are dangerous. It doesn't mean you should turn them off. It doesn't mean you need a fifteen step change control process for every plugin patch. Overreacting to the incidents of 2026 will lead to sites falling behind on the run of the mill CVEs that account for the actual majority of compromises. That's still where most sites get hit.

What it means is that auto updates are one layer, not the whole answer. They pair well with staging, with file integrity monitoring, with an inventory of what you have installed, and with the willingness to read a security advisory carefully before assuming a forced update has fully cleaned up whatever it patched.

The sites that come through 2026 in good shape will be the ones running that combined workflow. The sites still using auto updates as their entire security posture will be the ones the next supply chain incident hits.

Where this fits

The Protect My WP handbook is thirteen chapters on how to run a WordPress site so that when the trusted channel misfires, and it will, the specific thing that catches the problem is already in place. Chapter 8 covers the plugin update workflow in detail, including the staged rollout pattern above. Chapter 10 covers file integrity monitoring. Chapter 12 covers the wider maintenance cadence that ties it together.

If 2026 has made you reconsider how you handle WordPress updates, the book is the specific answer to what to do about it.

Get the book for £19.