We are currently waiting on several plugins to have security issues identified in part based on the results of our recently introduced tool for doing limited automated security checks of WordPress plugins to be fixed to be able to discuss real world examples of how the tool can be play a useful role in checking on the security of plugins.

One of the plugins we are waiting on shows the kinds of problems that come when trying to get vulnerabilities fixed in WordPress plugins, as the developer responded that the issues we notified them of had been fixed, but when we checked on the new version we found only two issues that we had identified as much less serious had been fixed. We had mainly mentioned those two because they were the issues that we picked up by the tool and we would be mentioning them in our post. For the issue we mentioned first in our message to the developer and identified as the more serious issue, no change was made.

In the meantime, though, we have made several updates to the tool that we though worth mentioning.

Expanded Reflected Cross-Site Scripting (XSS) Checks

For the plugin we mentioned earlier, one of the issues that tool picked up turned out to be unlikely to be exploitable, but provided an indication that the security of the plugin might be in poor shape in general, since it involved direct outputting of user input without it being escaped. When we went to do some more checking on the plugin we found a much more serious issue with the plugin. That seems to be a good indication that checking for fairly obvious security failures could be useful beyond just identifying those vulnerabilities, as it could identify plugins that are in greater need of a more thorough review than an automated tool can provide (like the security reviews we offer as part of our service and that can now be purchased separately as well).

When we went to take a look at what was done in the version that was supposed to fix the vulnerabilities we noticed a slightly more complicated path to reflected XSS also existed in the same file as the less complicated one our tool could already pick up. We have now added a check based on that.

While working on the new check mentioned in the next section of this post we ran across another plugin that had been picked as having the a reflected XSS based on the less complicated check. While looking into the details of that we noticed additional instances of that vulnerability in that plugin that were not yet picked up by that check and modified the check to catch those as well. There are likely a lot of other improvements we can make going forward as we start looking at if newly disclosed vulnerabilities in plugins are able to be picked up by the checks for those types of issues already in the tool.

Our First Third-Party Library Checks

One of the areas we are looking at adding checks for in the tool is insecure versions of third-party libraries. The first addition for that type of issue shows were the breadth of what we can do can help across all of them, as the libraries we added checks for are ones we only found that there was a security issue related to them when we looked into the details of a vulnerability that had been fixed in a plugin, but hadn’t had a public disclosure. That type of investigating is something that we look to be largely alone in doing when it comes to WordPress plugins as most providers of data on them either simply use other’s data (leading to lot of issues) or do little to no investigating into issues. In looking into that we noticed something else that lead to final new addition.

You Can Now Check Plugins Not in the Plugin Directory

In looking into the issue with those libraries we noticed that it looks like some of the plugins that have been using one of those libraries are either paid plugins or custom plugins. Up until now it would not be possible to check those plugins through our tool, since it only allowed checking plugins that are in the Plugin Directory. We have now added the capability for paying customers of our service to upload a ZIP file of a plugin to review, so they can have those plugins checked as well.

Unlike the checks of plugin in the Plugin Directory, we don’t record the identified issues for uploaded plugins since the checking of plugins in the Plugin Directory involves publicly disclosed code and that would not always be the case with uploaded plugins.

Going forward we might integrate the ability for the companion plugin for the service to handle of transmitting of plugins to our tool to make this type of checking easier. For now, there are a couple of plugins available in the Plugin Directory for downloading plugins as ZIP files.