A month ago while discussing a WordPress plugin that we had found a very serious vulnerability in the first version of, we noted that we couldn’t find mention of what was involved in the security review done before newly submitted plugins are allowed in to the Plugin Directory. After running into a couple of other vulnerabilities in new plugins that seems like they should have been caught during that review, but weren’t, we did some more looking and found what is reviewed and what seems to maybe more important, information on the people that run the Plugin Directory, who also do the reviews. What we found was in line with our dim view of how things are being handled when it comes to the security of WordPress plugins at this time and an indication that things are not likely to get better any time soon.

In the Review Checklist for plugin reviewers the security related section is as follows:

Security and Privacy

• Don’t phone home without informed user consent
• Collection of user data must be “opt-in” only and have the relevant option set to disabled by default
• Validate and sanitize untrusted data before processing (See: Data Validation)
• Escape all data before output (See: Data Validation)
• Do not use URL shorteners
• Use prepare() and $wpdb for SQL calls

What is lacking there are checks for the types of issue that are likely to lead to websites being hacked. What is important to note is that, based on our doing security reviews and lots of other checking of security issues in plugins, what they are doing would be much more time consuming to do well than to do checks for those more serious issues.

For example, the serious vulnerability we mentioned before was a PHP object injection vulnerability that was picked up proactive monitoring of changes made to plugins to try to catch serious vulnerabilities. That was picked up in one of two regex patterns we use for spotting that type of issue, both of which have very little chance of producing a false positive. Those checks are also included in our recently introduced plugin security checker. We would be happy to share those and the other similar patterns we use with the review team.

It isn’t as if the review team isn’t aware of that type of vulnerability, as one of them recently fixed a PHP object injection vulnerability in one of their plugins. Though as we noted in our posts of the details of the vulnerability they had not exactly been upfront as to the serious nature of the vulnerability, as this was the changelog entry for that:

• Security fix: Improved encoding of error cookies.

If someone on the bad side of things does the same kind of monitoring that we do, they would have recognized that the vulnerability had existed even if it hadn’t been disclosed.

Early this year we found two vulnerabilities in that same plugin while looking into the details of another vulnerability that had been fixed in that plugin.

That lack of security in one of the reviewer’s plugins is less concerning than an interaction we had with another member of the review team. Earlier this year we did a security review of a plugin by another member of the team. When we contacted them about the results they seemed have a hard time understanding that there was a vulnerability in their plugin and at one point seemed to think we were claiming that WordPress AJAX functionality itself was a vulnerability. It isn’t reassuring to see that person is someone that is supposed to be insuring the security of plugins. But it is in line with our having seen very vulnerable plugins returning to the Plugin Directory without the vulnerability actually being fixed. It also took five months for that vulnerability to get fixed.

The best experience we have had with a member of team in terms of contacting them about a vulnerability in one of their plugins, involved an arbitrary file upload vulnerability that likely was being exploited. That obviously doesn’t sound good, but this was a plugin that hadn’t been updated in 7 years and it was fixed the same day that we notified them of the issue.

That we have found vulnerabilities in plugins by three of the six members of the team in the normal course of our work doesn’t seems like it might not be a great indication of the quality of the team when it comes to security. The other way to look at that, is that the security of plugins is terrible, considering even the people handling security have problems, and that would seem to call for a very robust team to handle the situation. With only six members, that seems to be far from a robust team.

What we also found stunning was that while there are only six members on this team, they state that:

We are currently unable to accept new team members. Stay tuned!

The claimed reason for that is:

At this time, we are not accepting new reviewers due to technical issues.

It seems like at least more members are needed on the team (and probably more drastic improvements or changes to the team). It isn’t like there isn’t more that needs to be done than the current team is able to handle and there is even more that could be done beyond what really already should be being done.

The size of team seems especially undersized when you consider that there are over 52,000 plugins in the Plugin Directory.

While PHP object injection vulnerabilities have recently been very likely to be exploited, arbitrary file upload vulnerabilities have been very likely to be exploited for years. Despite that, the reviews are listed as not checking for that either. Within the last week our proactive monitoring of changes made to plugins to try to catch serious vulnerabilities has picked up two plugins with the possibility of that type of issue. In one of them we found that there was that type of vulnerability. In the other one we found that there was a more limited version, as you had to be logged in to WordPress to exploit it, but it is exploitable by even subscriber level users. With that one, if you were just to take a look over the plugin’s admin interface you would have seen that there was file upload capability and it wasn’t secure.

Without getting into the details since the vulnerability is in the process of being fixed, on one of the central pages of the plugin there is a files area:

When you click create you a taken to a page to upload a file:

If you try to upload a file with a .php extension that is not stopped:

This plugin also produces a lot of PHP notice messages when WP_DEBUG is set true, so depending what the reference to errors in the review guideline “No errors when run with WP_DEBUG set to true” that might have been something that should have led to the plugin being rejected.

Improving the Situation

All of this seems to point to there being value with the team starting to listen to people outside the team that could provide a perspective they clearly are lacking, but considering the head of the team has shutdown Support Forum conversations that tried to discus one of the problems with their handling of security, that seems unlikely to happen without major changes to the team.

If they ever get an interest in improving things instead of just trying to silence discussion of their problems, we would be happy to work with them to get the situation improved.