Why did Jetpack update automatically without my permission and with automatic updates disabled?

Curious, isn’t it?

It turns out that the Jetpack plugin updated itself to version 9.8 without asking permission, without intervention or information to the site administrator, and even if automatic plugin updates were disabled.

At 9.9 because I later manually updated it to that version

Even if you have disabled updates globally from the wp-config.php file with these constants:

/** Disable all automatic updates **/ define( 'WP_AUTO_UPDATE_CORE', false ); define('AUTOMATIC_UPDATER_DISABLED', true);
Code language: PHP (php)

Why did Jetpack update itself?

Well, the reason has been that the Jetpack team (from Automattic to be more precise) received a warning from a user that the image carousel module had a serious vulnerability related to the comments of the carousel images and, instead of releasing a new normal update, warning users that it was a major update, even serious, decided to opt for the fast track.

In fact, even in the plugin’s changelog, it appears as if the change was minor:

Doesn’t that sound like a serious security threat?

How did you update Jetpack with automatic updates disabled?

It turns out that one thing is automatic updates, introduced in WordPress 2.5, or background updates included in WordPress 3.7 and extended in version 5.6, and another is forced updates, something that has always been possible from the WordPress API.

This time, the Jetpack team contacted the WordPress security team (led by Matt Mullenweg, CEO of Automattic, coincidentally) and the WordPress Foundation, also chaired by Matt, and asked to force the upgrade to Jetpack 9.8 through this sort of WordPress backdoor.

Said and done, if you had Jetpack in any version from 2.0.8. to 9.7.1, the plugin updated itself without asking your permission, without even warning you, it was updated and that’s it.

It doesn’t matter if something was broken on your website or your clients’ websites, someone decided for you to update “that” plugin … for your sake, of course.

If it’s for my sake, what’s the problem?

If you see it like this, the debate is over.

When tomorrow other plugin developers decide to opt for this fast track of forced updates, it won’t matter what your decisions are about the updates of your website or those of your clients, they will update and you will sit and watch, is that ok?

But not only that, but there are also implications on privacy and security, or have you warned in your privacy policy that if the WordPress Foundation decides it can update your plugins without your intervention, no matter what implications this has for the security and/or privacy of your users?

Moreover, what right has the author of a plugin to ask for a forced update due to a security flaw in a module of the plugin that I may not even use but that can affect the rest of my website?

This update not only fixed the security problem, but also incorporated new features, such as stories, with their own privacy, SEO and content implications.

Did anyone ask you if you wanted to upgrade to even add these features?

Or else, what responsibility can we assume in front of our clients’ websites if we can’t prevent them from forcing an update of a component of their installations without even asking the administrators, maintainers and/or webmasters? does it seem half normal to you?

The issue I think is not minor and should open an important debate on what protocol should be followed to be able to use forced updates, under what circumstances and with what level of notice to users should be applied. But above all, a system to inform administrators prior to a forced update should be incorporated.

I personally believe that NOTHING justifies not informing/asking users for permission beforehand so that they can take preventive measures before forcing an update.

Moreover, I think this method of forced updates should be completely removed from WordPress, because someone could use it for any malicious use, and do not tell me that it is a safe method, nothing is safe on the network, everything that has created a developer can modify and use it another developer, and someone with bad intentions could use this possibility of the API to cause a massive infection of WordPress sites.

Can forced WordPress updates be avoided?

Yes, fortunately, you can add the following constant to the wp-config.php file:

define( 'DISALLOW_FILE_MODS', true );
Code language: JavaScript (javascript)

This constant disables everything related to WordPress installations and updates:

  • Notifications of updates
  • Install plugins
  • Install themes
  • Update plugins manually
  • Update themes manually
  • Updating WordPress manually
  • Automatic updates of everything
  • Background updates of everything
  • Forced updates of everything

Come on, everything. It’s a pretty radical option, and impractical even for webmasters, but given what’s happened it’s the only safeguard against forcing any updates on your sites or your clients’ sites again without warning.

What do you think about all this?

Click to rate this post!
[Total: 0 Average: 0]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top Skip to content