Version 9.8 included a security patch for all sites using the Carousel feature.

The vulnerability allowed the comments of non-published pages/posts to be leaked.

It was severe enough for the Jetpack team to work with WordPress.org to release 78 patched versions – every version of Jetpack since 2.0. Sites not using the Carousel feature were not vulnerable but could be in the future if it was enabled and left unpatched.

In a rare move, WordPress.org pushed a forced update to all vulnerable versions, surprising those who have auto-updates disabled.

Several Jetpack users posted in the support forums, asking why the plugin had updated automatically without permission and in some cases not to the newest version.

So this update was a forced update on WordPress sites even with auto-updates disabled?

We had this go live on a prod site at 2am last night that has auto-updates disabled for very specific reasons.

Not cool Jetpack. https://t.co/55upBmyeHp

— Brad Williams (@williamsba) June 3, 2021

Jetpack team member Jeremy Herve said the vulnerability was responsibly disclosed via Hackerone, allowing them to work on a patch for the issue. After it was ready to go, the Jetpack team reached out to the WordPress.org security team to inform them of a vulnerability impacting multiple versions of the plugin.

“We sent them the patch alongside all the info we had (a PoC for the vulnerability, what features had to be active, what versions of Jetpack were impacted),” Herve said. “They recommended we release point releases for older versions of Jetpack as well.

“We created those new releases, and when we were ready to release them, someone from the WordPress.org team made some changes on the WordPress.org side so folks running old, vulnerable versions of the plugin would get auto-updated, just like it works for Core versions of WordPress.”

Jetpack team member Brandon Kraft estimated the number of vulnerable sites at 18% of the plugin’s active installs.

He said that Jetpack was not part of the discussion about the pushing out a forced update.

FTR, Jetpack did not decide this. We learned of the security issue, brought it to the WP Plugins team who advised we create patched versions for all impacted. The WP Meta team modified the API to push it.

Decision to push was not ours nor should it be.

— A Guy Called Kraft 😷💉 (@Kraft) June 3, 2021

“What probably adds to the confusion is that WordPress 5.5 added a UI for plugin (and theme) autoupdates,” Herve said. “That UI, while helping one manage plugin autoupdates on their site, is a bit different from Core’s forced update process. Both of those update types can be deactivated by site owners, just like core’s autoupdates can be deactivated, but I don’t believe (and honestly wouldn’t recommend) that many folks deactivate those updates.”

Brandon Kraft dug deeper into the topic and published a post that explains the differences between auto-updates and forced updates. It includes how to lock down file modifications if you don’t want to receive any forced updates in the future. Forced updates, however, are exceedingly rare, and Kraft counts only three for Jetpack since 2013.

In this instance, the Jetpack team followed the official process for reporting a critical vulnerability to the plugin and security teams who determine the impact for users based on a set criteria.

Users who received an email notification about an automatic update from Jetpack, despite having the UI in the dashboard set to disable them, should be aware that these forced updates can come once in a blue moon for security purposes.

Tony Perez, founder of NOC and former CEO at Sucuri, contends that forcing a security update like this violates the intent users’ assign when using the auto-updates UI in WordPress. He highlighted the potential for abuse if the system were to become vulnerable to a bad actor.

“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,” Perez said.

“Put plainly, it’s an abuse of trust that exists between the WordPress user and the Foundation that helps maintain the project.”

“My position is not that it shouldn’t exist. That’s a much deeper ideological debate, but it is about respecting an administrators explicit intent.”

Source: Sarah Gooding – WordPress Tavern