Plugin Security

The security of code in WordPress plugins is taken very seriously.

Warning: If you have found a plugin with a security issue, please read Reporting Plugin Security Issues

When a plugin vulnerability is verified by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.

Automatic Plugin Security Updates Automatic Plugin Security Updates

Since WordPress 3.7, we have had the ability to push automatic security updates for plugins to fix critical vulnerabilities in plugins. Since then, 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.

In extreme situations, the Plugin Review Team and the WordPress Security Team may determine a plugin issue is great enough that it must be updated for all users. This is exceptional rare, as the potential for conflicts is high.

What is the process for the security team to push an update for a plugin?

The 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.

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.

While the process is still relatively new, the current criteria we take into consideration for a security push is a simple list:

  1. Has the security team been made aware of the issue?
  2. How severe is the issue? What impact would it have on the security of a WordPress install, and the greater internet?
  3. Is the fix for the issue self-contained or does it add significant extra superfluous code?
  4. If multiple branches of the plugin are affected, has a release per branch been prepared?
  5. Can the update be safely installed automatically?

These requirements are defined in a way that anyone should be able to tick each box.

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 with the details.

The plugin and security teams will 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, it is preferable to see plugin releases which fix only the security issue, with minimal code changes and with no unrelated changes. It allows everyone 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.

Code changes should be minimal. The plugin shouldn’t require additional assistance during the update process in the form of user interaction or an upgrade routine — the process should “just work” every time.


Q: Why did plugin A get a automatic update, but plugin B didn’t?

It’s not bias from, 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.

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 with as much detail as possible. 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.