The Core systems team of WordPress had an eventful Friday when an auto-update framework mistake caused sites to update to WordPress 5.5.3-alpha-49449.
Including live sites where there are no defined auto-update constants.
Many who have received an email about the update have signed on to their sites to see the message:
“BETA TESTERS: This site is set up to install updates of future beta versions automatically.”
The first ticket about sites being updated to 5.5.3-alpha-49449, which was also interestingly his first WordPress trac ticket, was logged by Shaun Rieman. The problem has been verified by more users and developers.
“It is worth noting that between 5.5.2 and 5.5.3-alpha there is no functional difference, so there is no need to think about that,” said core committer John Blackbourn.
All the default themes released over the past decade, as well as Akismet, were also installed by sites that were unintentionally modified. The bundled themes that they do not need would need to be manually removed by developers.
All impacted locations were automatically restored to 5.5.2 in less than an hour, but the incident undermined confidence and weakened confidence in the auto-update system. Several comments on the ticket asked how they could specifically disable updates for growth.
The troubling thing is that, apparently without any testing or clarification by other developers, a single developer can do this, “said UK-based developer Paul Stenning.” “It is a major security problem because in an update that nobody else reviews, a rogue developer might push out malicious code.”
Rob Migchels, the owner of WordPress agency, who had approximately 50 impacted websites, monitored 18 minutes between the trac ticket (# 51679) and obtained the patch.
Security researcher Slavco Mihajloski, who commented last week on the lack of clarity on how to evaluate and execute automated updates, said this incident highlights the need for more process openness.
“Why is transparency important? Because procedure will become public and when public, the community will be able to contribute in order to improve it,” Mihajloski said.
“At the moment it is more than obvious that this process and the whole security at WP.dot org lacks QA and QC. Each task is left to an individual or closed group. Imagine the following: what if an automatic security update could be pushed only if: – X out of Y (where X < Y) authorities agree that update is fine – have a pilot update on let’s say 100 different servers (I hope .org could afford this) where regression tests will be fired against each one. The current problems would not occur.”
Automatic context updates for minor releases have saved thousands of hours of site updates for developers. On the roadmap for WordPress 5.6, expected in early December, there is a UI to enable users to opt for automatic updates for big releases.
For many developers, this particular accidental update has betrayed what was already a very shaky confidence in the auto-update framework. When 5.6 is released, it does not shore up further faith to sell the concept of core updates, but it does not mean that auto updates are not a good idea. To gain back the trust of users, WordPress.org would need to put better processes in place.
More than 100 pages for WordPress agency owner Robert Staddon were impacted by the incident. He states that with the confusing and incorrect text shown below, they all showed the “Update now” button. Staddon said the incident has not yet led him to change his approach to enabling auto-updates to be received by customers.
Although this affected people with auto-updates turned off, this is a good example of why we choose to select manual updates, just incase it breaks your site, you’re at the computer to fix the problem.