The release of WordPress 3.7 introduced a feature that was met with mixed reactions: automatic background updates. In all versions after 3.7, WordPress completes minor updates without asking for permission.
Left to their own devices, site owners often neglect to perform updates. Updates – particularly the minor updates that can be applied automatically – include security patches that fix known vulnerabilities. If the updates aren’t applied to a WordPress site, it remains vulnerable. If the vulnerability wasn’t widely known in the criminal community, it will be after a patch is released, increasing the risk to sites that fail to update. The sooner sites are patched, the better. But many in the WordPress developer and professional communities weren’t impressed with automatic updates.
Updates sometimes break WordPress sites. This happens rarely, but whenever part of a complex system changes, so do its interactions with other parts of that system. An update may stop a plugin from working or cause a regression – a bug introduced when another bug is fixed or feature added.
It’s not impossible that a minor security update could stop a WordPress site working, but ask yourself how often you’ve seen that happen when applying a minor update to a production site. And then ask yourself how many hacked WordPress sites you’ve come across. Compare the two numbers and I think it’s fair to say that it’s a risk worth taking.
Some argue that automatic updates introduce a security risk. If the servers hosting the updates are compromised, criminals could inject malware into the update files and infect hundreds of thousands of sites. It would be nice if WordPress introduced code signing to further reduce the risk, but in reality the likelihood of this chain of events occurring is vanishingly small. And it’s certainly smaller than the risk of leaving sites unpatched.
Finally, some people simply want complete control over what’s installed on their site. Automatic updates don’t sit well with them. That’s fine: control over your own site and content is what WordPress is all about. But that has to be balanced against the potential risk if security problems aren’t dealt with. If you’re a responsible WordPress site owner, you’ll apply the patch eventually. If you plan to pore over the code before you patch, then you’re probably not the target market for automatic updates. If your objection is simply to the concept of automatic updates, that’s your choice, but you shouldn’t make that choice for less technical users for whom you build and manage sites.
Earlier this year, a vulnerability in the newly introduced WordPress REST API lead to the defacement of a large number of WordPress sites. The patch to fix the vulnerability was released immediately after the problem was discovered and pushed out as an automatic update. Sites with automatic updates turned on – the default state – are no longer vulnerable. And yet, we’re still seeing many thousands of sites fall victim to the attack. The obvious conclusion is that some people think turning automatic updates off is a good idea.
There’s nothing wrong with turning off the automatic updates in principle, but if you provide a client with a site that has automatic updates turned off, you have a responsibility to make sure security updates are applied in good time. If you’ve turned off automatic updates on your own site, it’s up to you to manually update at the earliest possible opportunity.
Otherwise, the smart thing is to leave automatic updates turned on and let them do their job.