On June 1st, Automattic’s JetPack plugin released an update to patch an exploitable vulnerability. The vulnerability was found in their Carousel feature. The release invites plugin users to update their version. It warns that while it’s not known to be actively exploited it could be now that it’s been released.
One thing it fails to do is notify the users that it will be deploying the update automatically using the built-in forced update feature in core. Since originally posting, I have also learned this decision was made by the WordPress Meta / Security team, not Automattic / JetPack.
Regardless of which side of the aisle you fall on with regards to whether auto / forced updates should, or should-not, be leveraged, there has always been one common theme in the world of security:
These types of updates present a danger in where a system can now arbitrarily make changes to a site without user consent. This is especially dangerous when put into the hands of a bad actor, or an ignorant system that does something with good intention but with horrible results.
Update: Since the original post a couple things were highlighted by a number of community members that require an edit to the original post:
1 – The decision to update was made by the Meta/Security team with the WordPress Foundation (not Automattic, or JetPack);
2 – It’s important to differentiate between Auto-Updates and Forced Updates. While Auto-updates were introduced in 5.5, Forced updates have always been in the WordPress platform as a means to an end.
Even with this update, this does not do away with the very real concern that comes with having this capability. We don’t need to look far to see why having this capability is very dangerous.
Disabling Auto-Updates with WP-CONFIG Hooks
One way to address this is leveraging the WordPress hooks to disable auto-updates in the wp-config.php file (note that this does not disable Forced updates which is what was used in this scenario):
Core:
define( 'WP_AUTO_UPDATE_CORE', false );Plugins
add_filter( 'auto_update_plugin', '__return_false' );Themes
add_filter( 'auto_update_theme', '__return_false' );These hooks empower the site administrator to choose when updates can occur. At least they should, right?
Impacts of Ignoring User-Defined Settings (Intent)
The decision to push this forced update was made by the Meta/Security team with the WordPress.org team. As JJJ explains, the forced functionality has been around forever and it’s in place as a means to keeping the web safe. Used in rare, and discretionary times.
This does beg the question, was the situation now that warranted this kind of push?
I made the mistake of not differentiating Forced from Auto-Updates, but if we’re being honest it feels like a pot and kettle conversation. What’s the difference?
Why would WordPress believe that a user is ok with Forced updates, when they have explicitly decided not to allow auto-updates. And if a Forced update is pushed, shouldn’t there be some level of transparency to understand how, and why, that decision was made? Surely it’s aligned with some decision making framework that is tied to impact and severity, right?
I still stand by the position that even with a forced update, the platform is making an active decision that is arguably contrary to what the site administrator is intending when they explicitly say they don’t want something done. Put plainly, it’s an abuse of trust that exists between the WordPress user and the Foundation that helps maintain the project.
Brad Williams, the owner of WebDevStudios, an agency specializing in building complex web applications for enterprise customers using WordPress explains it best:
We agree whole-heartedly with Brad on this.
We’re not questioning the need for an auto-update feature, or even a Forced feature. We are, however, calling into question the ability for a system to override a users preference (intent).
In security, this is a backdoor. Only thing distinguishing it is is intent.
This type of action should force every WordPress administrator to reconsider how they manage their WordPress deployments. Consider going beyond the provided hooks to server-level hardening that would prevent components from writing to itself.
Concern for Platforms that Have the Ability to Force Action
When I first wrote this article I made a mistake not distinguishing between Auto-Updates and Forced updates and called out Automattic and JetPack, I was wrong. It does not do away from the core point – should a platform have this level of control?
While I can appreciate JJJ’s position on the necessity for creating a safe web and tackling egregious exploits that are circulating, we can’t dismiss the reality that is a supply chain attack. We don’t have to look that far to see how horribly wrong this can go, 2020 US Federal Government hack that was facilitated by SolarWinds.
The attack involved hackers compromising the infrastructure of SolarWinds, a company that produces a network and applications monitoring platform called Orion, and then using that access to produce and distribute trojanized updates to the software’s users.