Automatic Plugin Security Updates
The WordPress.org security and plugin review teams have recently been working together to push automatic security updates for plugins to fix critical vulnerabilities. These updates are supported by WordPress 3.7+.
Andrew Nacin, a fellow lead developer of WordPress who helped write this post, wrote this after WordPress 3.7 was released:
“The automatic updater also supports themes and plugins on an opt-in basis. And by default, translations (for themes, plugins, and eventually core) are updated automatically. At some point in the future, the WordPress.org plugin security team will be able to suggest that installs automatically update malicious or dangerously insecure plugins. That’s a huge win for a safer web.”
Some have interpreted this as the end-user is required to opt-in, but it’s always been the case that it could be opt-in by either the site administrator, or by the WordPress.org security team if we deemed an issue severe enough to warrant it.
Back in April of 2014, the WordPress.org security team was contacted by Automattic with the details of a security issue affecting Jetpack, looking for help to get the update out to affected users as fast as possible (you can read more about that release over on the Jetpack Blog).
The team ultimately decided that leveraging our ability to issue a background update was the best option for the security of any WordPress site running the plugin. This decision was not made lightly, as it was the first time we would use the functionality.
A situation where we would have used automatic plugin updates was the security incident in July of 2011 where accounts of three plugin authors were breached and malicious updates were released. We were able to confirm that no other plugins were affected, as a precaution we reset the passwords of all WordPress.org users, but tens of thousands of sites were updated to a malicious version during a narrow window.
Unfortunately we weren’t so lucky back then, as we didn’t have automatic updates available to us. Thankfully, the malicious updates were detected quickly. But if a plugin author’s account is ever compromised again in the future, we’ll be able to remove the malicious update, and then push a security update for any site affected ASAP.
Since WordPress 3.7 was released, many sites have used the plugin automatic updates functionality, either by opting in directly through filters, or by using one of the many remote management services for WordPress that are available. We’ve had very few bug reports from those early users of the automatic plugin update functionality.
What is the process for the security team to push an update for a plugin?
The WordPress.org security team has only recently started to push more of these updates, only a handful of plugins have received the treatment, with vulnerability severity ranging from major to critical, affecting anywhere from 10,000 active installs to more than a million (Such as the WordPress SEO plugin this past week).
The process of approving a plugin for an automatic update, and rolling it out to WordPress users, is highly manual. The security team reviews all code changes in the release, verifies the issue and the fix, and confirms the plugin is safe to trigger an update. Rolling out an automatic update requires modification and deployment of the API code. This is the same standard and process for a core security release.
Because the process of pushing these updates is relatively recent, we haven’t previously formulated any guidelines as to when these pushes happen. We’re still iterating on them, but the current criteria we take into consideration for a security push is a simple list:
- Has the security team been made aware of the issue?
- How severe is the issue? What impact would it have on the security of a WordPress install, and the greater internet?
- Is the fix for the issue self-contained or does it add significant extra superfluous code?
- If multiple branches of the plugin are affected, has a release per branch been prepared?
- Can the update be safely installed automatically?
These requirements are defined in a way that anyone should be able to tick each box. (If a plugin author needs help, we’ll help them to make that happen.)
The first criterion — making the security team aware of the issue — is critical. Since it’s a tightly controlled process, the WordPress security team needs to be notified as early as possible. Letting us know is as simple as emailing us at [email protected] with the details. If you’re not the plugin author, we’ll put you in touch with the plugin author and help coordinate the fix.
We’ll work with the plugin author (and the reporter, if different) to study the vulnerability and its exact exposure, verify the proposed fix, and determine what versions will be released and when.
As with WordPress core security releases, we prefer to see plugin releases which fix only the security issue, with minimal code changes and with no unrelated changes. It allows us to review the changes quickly and to be far more confident in them.
If a plugin has a security vulnerability in versions 2.0–2.1.1, and 2.1 introduced several new features but 2.1.1 only fixed a few minor bugs, we’d enable an automatic update for 2.1.x to 2.1.2 but not for 2.0.x to 2.1.2. If a significant amount of installs still used 2.0, we’d ask for a 2.0.x release to be made, which 2.0.x users would be updated to, securing their installations, but without significantly changing the plugin they run. (For Jetpack’s release, release packages were generated from 11 different branches.)
We want code changes to be minimal. The plugin shouldn’t require additional assistance during the update process in the form of user interaction or an upgrade routine — we want the process to “just work” every time.
Millions have received automatic updates for security releases of WordPress core. We want automatic plugin updates to be as safe, and as trusted.
We hope this clarifies why and when we’ll push automatic plugin security releases. It isn’t a decision we make lightly. The WordPress.org security and plugins teams only want to make the web a safer place for you and your visitors.
FAQ
Q: Why did plugin A get a automatic update, but plugin B didn’t?
It’s not bias from WordPress.org, it’s just a throwback to the manual process we’ve been using. If we’re alerted to an issue, we’ll work to handle it. If we find out several days later, the window of opportunity to get the fix rolled out has usually passed and it won’t be as effective.
If any plugin authors reading this have recently issued a security update and would like us to consider pushing an automatic update for the remaining users, please get in touch with us and we’ll do whatever we can to help.
Q: I keep my plugins updated already and don’t wish to have plugin security updates pushed automatically. How can I disable them?
There are several options to disable this functionality. The previous article for disabling core automatic updates applies here. Anything that disables all automatic update functionality will prevent plugin updates.
If you only wish to disable plugin updates, whether for all plugins or a single plugin, you can do so with a single filter call. See this Codex article for more.
Q: If I discover a security issue in my plugin, what should I do?
Email [email protected] to seek support from us. We’re here to help you. You should start working on a fix for the issue, and share a patch of the changes for review before you release it if you want us to review the change or if you think an automatic update could be needed.
Q: Will you ever push an automatic theme update?
One day, perhaps — but not until we can do this safely. This is a complicated problem to solve. We don’t currently have a way to verify whether a theme was edited to customize a site. We never want an update to break a site or lose customizations.
You can always enable automatic theme updates using the filters outlined in this Codex article. Also, the theme review team catches most issues long before the theme is available for download, making theme updates far less likely to be needed.
Q: How can I get involved with the plugins review team?
As the plugins team deals with very sensitive issues, it’s a small group of well-known, highly trusted community members. It’s grinding work with a seemingly never-ending queue. If you’re interested, email [email protected].
Q: How can the WordPress security team trigger a background update for a plugin?
The auto_update_plugin filter is run on a flag present in the plugins update API response. By default, the flag is false, but it can be specifically enabled for a plugin. Core and translation background updates use the exact same mechanism, the only difference being their API responses have the flag enabled by default.
Ahmad Awais 7:27 pm on March 14, 2015 Permalink | Log in to Reply
Hey Dion,
I think it is a great step forward in ref to web security and it might keep WordPress from earning a bad name due to such hacks.
That said.
It’s great to find out that plugin review team will be closely working with us (plugin authors) to troubleshoot such situations.
Rafael Ehlers 7:34 pm on March 14, 2015 Permalink | Log in to Reply
Thanks for this post, Dion.
Here’s a *personal* tip to Plugin authors: if you ever get contacted by a “security company”, that is notifying you about a security breach on your code. As soon as you fix the code, talk to the security team at wordpress.org FIRST. Then if your fixed code is approved by the .org team to be on an automatic update, feel free to reply back to the “security company” mentioning that your code is fixed. Otherwise they’ll disclose it on the same day as you push your new code to the repo. And your users won’t have enough time to be notified about the fix to update. Trust me, *hackers/crackers* are faster to exploit that breach on your users website than they can update your plugin. That’s because we still don’t have a clear policy on the WordPress community about the amount of time a plugin author have to work, before the breach goes public. And that’s where the problem is.
Stephen Edgar 2:11 am on March 15, 2015 Permalink | Log in to Reply
Thinking out loud…
Presumably this would need reviewing on a case by case basis but I think worth thinking about how this may affect your plugin nonetheless.
Jon Brown 5:40 pm on March 15, 2015 Permalink | Log in to Reply
I was wondering about something along these lines too. Can these auto-updates only target certain version numbers?
If 2.1 was secure, but 2.2 introduced a vulnerability that went unfixed through version 3.0. Can updates be forced only on 2.2-3.0 installs? or would the secure 2.1 instances get updated as well? (For reference this was an issue with TimThumb were hosts were going around warning about and updating ancient but secure versions of TimThumb).
P.S. Thrilled this conversation is happening and full support clarifying the policies around this and encouraging more of it.
Andrew Nacin 7:11 am on March 16, 2015 Permalink | Log in to Reply
Yes, auto updates can target specific version numbers.
Andrew Nacin 7:14 am on March 16, 2015 Permalink | Log in to Reply
The answer is yes. All version criteria can be determined on a case-by-case basis, however.
deltafactory 8:00 pm on March 15, 2015 Permalink | Log in to Reply
What has been discussed internally as far as complex upgrade scenarios and perhaps multiple minor upgrade paths?
For example, based on a very recent situation:
WooCommerce patched a vulnerability in v2.3.x that also exists in v2.2.x etc. The jump to v2.3 is non-trivial for many of us who would otherwise opt in to automatic updates. Would it be possible to push an update as v2.2.12 to address the bug with minimal other changes for v2.2.x users, while v2.3.x users receive v2.3.6?
The exact upgrade criteria and releases would be within the control of the plugin author. I’m just suggesting that there is a way for those closest to the code to determine whether the side-effects may cause more harm (to the reputation of the site owner, plugin author, WordPress, and the auto-upgrade system) than the fix.
Andrew Nacin 7:13 am on March 16, 2015 Permalink | Log in to Reply
The post spent a few paragraphs on this. (Look for the word “branch”.) We’ve done this a few times, including for WordPress SEO.
The exact criteria is in the hands of the security team. The plugin author can advise, but we must consent.
Tom Lany 10:28 pm on March 15, 2015 Permalink | Log in to Reply
Last week, I was working to upgrade plugins on a couple of WordPress websites. I manually updated the WordPress SEO plugin on one site. Then, I logged in to another site, thinking that I would need to complete the same upgrades. Once logged in, I saw that the WordPress SEO plugin had already been upgraded. While this is good, I was confused, as I knew I had not updated it myself, and I am not used to automatic plugin updates. Before doing some research and finding out that this update had been pushed out, I wondered if my site had been hacked.
I did not receive an email indicating that this plugin was updated, in the way I do when maintenance releases are automatically installed. It would have been very helpful if I would have received an email notification when this plugin was updated.
Thanks for posting about how this process works. It’s great to hear about the commitment the security team has to keeping WordPress installations secure.
Dion Hulse 6:31 am on March 17, 2015 Permalink | Log in to Reply
It’s certainly strange that you didn’t get an email, as emails should be sent out by default. I had seen others post screenshots to Twitter of it, so it’s possible a spam filter has blocked it..
Derek Herman 1:48 pm on March 16, 2015 Permalink | Log in to Reply
Could we add an admin notice that references what was automatically upgraded and why to minimize confusion for end-users?
Dion Hulse 6:33 am on March 17, 2015 Permalink | Log in to Reply
I’d like to add a “Update History” to the Dashboard -> Updates page which lists what updates have occurred on a site (either manual or automatic), having an admin notice to go along with that isn’t out of the question
We’ll see what the WordPress 4.3 dev cycle brings with it.
Soflyy 2:31 am on March 18, 2015 Permalink | Log in to Reply
There was a massive security hole in WP All Import that we just patched. I saw this thread so I thought “Yeah, we should probably push that out as an automatic update.”
I sent an e-mail to [email protected] informing them of the situation. 30 minutes later Dion Hulse got back to me saying 3.2.5 looked good for an automated update, and pushed it out.
No back and forth. No headache. Nothing complicated.
7900+ downloads of the update today and not a single report of a problem so far.
Wow.
A+.
Plugins team, thank you so much. This is awesome.
Rene Hermenau 8:35 am on March 18, 2015 Permalink | Log in to Reply
@Soflyy, this is remarkable and best proof that the wp core team is really dedicated to fixing any security issues asap. Thumbs up!