Back to Articles

WordPress Forced Updates vs Auto-Updates and Abusing User Defined Intent

By Tony Perez (@perezbox) • Posted in: wordpress-security •

On June 1st, Automattic’s Jetpack plugin released an update to patch an exploitable vulnerability in the Carousel feature. The release invited users to update and noted it wasn’t known to be actively exploited at the time—but could be once disclosed.

One thing it didn’t make obvious at first: the update would be deployed automatically via WordPress’s forced update capability. Since originally posting, I learned this decision was made by the WordPress.org Meta/Security team—not Automattic/Jetpack.

Whether you fall for or against forced updates, a long-standing security concern remains: these mechanisms let a system make changes without explicit, immediate consent. In the wrong hands—or with good intentions but poor outcomes—that’s risky.

Update: Two clarifications surfaced after the original write-up:
  1. The decision to update was made by the WordPress.org Meta/Security team (not Automattic/Jetpack).
  2. Auto-updates (introduced in 5.5) are different from forced updates. Forced updates have existed for years as a last-resort safety valve.

This doesn’t erase the core concern about the capability itself.

Disabling Auto-Updates with WP Config & Hooks

You can control auto-updates with constants and filters (note: these do not disable forced pushes):

Core (in wp-config.php):

define('WP_AUTO_UPDATE_CORE', false);

Plugins (plugin or mu-plugin code):

add_filter('auto_update_plugin', '__return_false');

Themes (plugin or mu-plugin code):

add_filter('auto_update_theme', '__return_false');

These settings express administrator intent about when updates should occur—but they don’t apply to rare, centrally triggered forced updates.

Impacts of Ignoring User-Defined Settings (Intent)

The WordPress.org team’s rationale is safety of the wider web, and as JJJ notes, the mechanism is meant for exceptional cases. Reasonable people can still debate: did this rise to that level?

I initially conflated auto-updates and forced updates (mea culpa), but from an admin’s perspective it still feels like the platform is overriding an explicit choice. At minimum, forced pushes should come with transparency about the criteria and process behind them.

We agree with the sentiment: it’s about respecting user intent. Features that can override that intent should push implementers to harden beyond WordPress hooks—e.g., server-level controls that prevent components from modifying themselves.

Concern for Platforms with the Ability to Force Action

While I was wrong to pin this on Automattic/Jetpack, the broader question stands: should a platform retain unilateral ability to push changes into production sites? History shows supply-chain risk is real (e.g., SolarWinds/Orion). Intent is the only difference between a safety valve and a backdoor.

The SolarWinds attack compromised vendor infrastructure to distribute trojanized updates to customers. The mechanism that makes broad updates easy also makes broad compromises possible.