We review a lot of publicly disclosed vulnerabilities in WordPress plugins for our service and in doing that we have noticed that many of those are found in little used and not recently updated plugins. What we had come to assume is that this was due to more popular plugins having been more thoroughly checked over and any vulnerabilities being quickly fixed if they were introduced in to the code. While preparing to do some research recently we came across evidence that shows this is not the case. That obviously isn’t a good sign for the security of WordPress based websites, but it also does show an area where a major improvement to the security of them can be made fairly easily.

Our discovery started when we wanted to see about reviewing some of the most popular WordPress plugins for an error in implementing one of WordPress’ security features that we had seen be the cause of vulnerabilities in several widely used plugins. To do this we first needed to automate downloading of some of the most popular plugins, since we didn’t want to have to individually download them. The Plugin Directory includes a section that lists 1,000 most popular plugins, which made most of the job easy. We just go through those pages of that section getting the addresses of the plugins, then getting the download link from the plugins’ pages, and finally download the plugins. While testing the code to do that we first got a hold of the 100 most popular plugins. Once we had that we did some really basic searches on their code looking for any obvious vulnerabilities. We assumed that there wouldn’t be any in such widely used plugins, but that turned out to be wrong.

A reflected cross-site scripting (XSS) vulnerability involves a situation user inputted value containing malicious code in some form of scripting, usually JavaScript, is submitted to a website and the resulting page includes that malicious code. This type of a vulnerability doesn’t appear to be a major threat at this time since it requires getting someone to a specific URL and all of the major web browsers other than Firefox now provide filtering to prevent this type of vulnerability from being exploitable in most cases. But its presence is an indication of less than ideal security practices since it involves a failure to properly sanitize user input, which is a basic security practice.

One of the searches we did on those 100 most popular plugins was for the direct echoing of a POST value, which would likely allow for a reflected XSS. That searched brought up two lines that allowed that allowed for a reflected XSS in the BackWPup plugin, which has 400,000 active installs. You can find more details of the issue in our post disclosing that vulnerability. That vulnerability surprised us, but our surprise turned to concern when we tracked back that the vulnerable code’s introduction to July 21, 2012. Within a day of  us notifying the developer of the issue, the vulnerability was fixed, so it seems unlikely that this had been reported to them before and ignored. The fact that such an easy to find vulnerability had remained unnoticed in the code of such a popular plugin for so long is pretty disturbing.

We are currently in the process of reviewing those popular plugins for other easy to spot issues and have already found a number of that we are in the process of trying to make sure get fixed.

One outcome of us becoming aware of this situation is that we are now making available ZIP archives of popular WordPress plugins so that if someone wants to review them they can get a hold of them without having to individually download them or create their own software to handle the task. Hopefully that will lead to more people looking at them.

This situation also suggest that a concerted effort to perform security reviews on the most popular plugins is warranted and could have real impact on the security of WordPress based websites. We continue to think that Automattic has a responsibility for improving the security of WordPress plugins, so underwriting this would seem to be a good move for them.