Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#50778 closed defect (bug) (duplicate)

5.5 auto updates should not be enabled by default for external plugins

Reported by: dennis_f's profile dennis_f Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.5
Component: Security Keywords: needs-privacy-review
Focuses: Cc:


Auto updates can be a security issue when enabled for external plugins by default.

I myself had a major problem with this feature and my plugin that is not hosted on At this point, the plugin hooks into the updates api, so you can update the plugin manually from the dashboard. With the automatic updates however I had mixed results - sometimes they worked, sometimes they didn't.

The worst part is that a few times the plugin's update notification disappeared completely after the failed automatic update attempt.

Of course I'm going to release an update to somehow handle this situation, but I am very worried that many people will not install this update before enabling automatic updates. And when their update notification disappears after a failed update, they will not know that they are running an outdated version.

I imagine that my case won't be the only one. Additionally as @stephencronin raised his concern here, this can also lead to false sense of security for plugins that don't support dashboard updates. People will think that their plugins are up to date when they are not.

Automatic updates should be only enabled for plugins and those plugins that support it implicitly. Otherwise this could lead to people using outdated and vulnerable versions of plugins without being aware of it.

Change History (6)

#1 @SergeyBiryukov
4 years ago

  • Component changed from General to Security
  • Version set to trunk

#2 @apedog
4 years ago

I would tend to agree with the the ideas set forth by @stephencronin in the make post discussion linked above.
Plugins should be required to opt-in to auto-updates if (and only if) they have an update mechanism. Whether they be repo plugins or "in the wild"/private plugins using a custom updater.

Also related:
Request a plugin header field that allows a plugin to self-identify as a non-repo plugin.
This is necessary for custom or private plugins (with or without custom updaters) that have a naming-conflict with plugins in the repo.
If at any point a plugin with a naming-conflict is deactivated - core will assume it's a plugin and attempt to update from Effectively replacing the plugin with another.

This ticket was mentioned in Slack in #core by apedog. View the logs.

4 years ago

#4 @carike
4 years ago

  • Keywords needs-privacy-review added

Don't mind me, just adding this to our workflow as well :)

#5 @apedog
4 years ago

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #50280.

I'm pretty sure this is a duplicate.

#6 @SergeyBiryukov
4 years ago

  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.