If you are the developer of a WordPress plugin and wondering if you should get a security review of your plugin done or when you should get one done, we have answers. To better answer those questions, we will first look at a couple of recent situations involving serious security vulnerabilities in WordPress plugins we help to address where security reviews hadn’t happened.

In late January, an unfixed vulnerability was widely exploited in a WordPress plugin with 40,000+ installs leading to negative reviews of the plugin with headlines including “Malware vulnerability with the latest version”, “Never ever install this! It makes a bug!”, and “Compromise plugin, do NOT install”. That obviously isn’t what any plugin developer wants and hopefully they don’t want someone using their plugin to get hacked.

One of the notable elements of that situation was that three major WordPress security providers WPScan (owned by Automattic), Wordfence, and Patchstack had all falsely claimed that the vulnerability, while incorrectly describing it, had been fixed three months before it was widely exploited. That claim had started with someone having run across the issue and submitted it to WPScan.

Once we notified the developer it still existed, they promptly fixed it and then they hired us to do a security review of the plugin to make sure it was fully secured. If they had a security review done before this by someone who knew what they were doing, then the vulnerability could have been caught and fixed before the exploitation happened.

Another recent situation with a serious vulnerability didn’t go as badly, as the vulnerability was caught before there was at least any widespread exploitation of the vulnerability. That situation involved a plugin with 3+ million installs from a developer who is also the developer of a 1+ million install security plugin. You would reasonably expect them to be on top of security. You might also expect that if a serious vulnerability is introduced in to such a popular plugin that it would be noticed in a timely manner, as a claimed benefit of open source code is that others can review the code and help to catch security vulnerabilities.

Instead, the vulnerability was in the plugin for over 6 months before we ran across the two security failures that led to it, while looking into another security change (because at least one of our customers was using the plugin). One of the security failures was something that is easy to check for, yet in over six months no one had done that, and we only did that because of another security issue. The developer said that updates go through multiple reviews, yet they missed that.

You Should Get a Security Review

If you haven’t had your plugin go through a security review, then you should get one done. As the examples above show, relying on others reporting security vulnerabilities to you isn’t going to produce good results. Not only will many issues not get caught that way, giving a hacker a chance to find them first, but the reporters often don’t check to make sure they are fixed.

We often are trying to address security issues that haven’t actually been fixed with developers who make strong claims about security or are the providers of security plugins (sometimes involving their security plugins), so even if you think you have a good grasp of security, you can have missed something. Having someone else that is experienced in doing security reviews is likely to catch it.

A Security Review After Major Changes is a Good Idea

We sometimes see people talking as if a plugin hasn’t been updated in a long time it is somehow insecure, as if it is milk that goes bad. That isn’t the case. In theory, a new type of security vulnerability could be found that means code that was seen as secure before isn’t secure anymore, but in most cases serious vulnerabilities are caused in part by failures to do basic security, so code seen as secure before, should remain quite secure.

If major changes are made to the plugin, then a previously secure plugin can become insecure. Here is how the change that introduced to that 3+ million plugin was described:

The issue was introduced in a release of UpdraftPlus in the second half of 2022, as a result of moving existing code around in order to prepare the way for future improvements in that code. This resulted in code that previously had not been reachable without the appropriate permissions check being accessible without it.

So if major changes have been made, then getting another security review done is a good idea.