Back in 2012, years before we started this service we noticed a couple of big problems with how security issues in WordPress plugins were being handled. The first one was that there were many vulnerabilities that existed in the current versions of plugins that had been publicly disclosed, but the plugin remained available in the Plugin Directory. The second was that when a vulnerability in a plugin was reported to the Plugin Directory the plugin was removed from it, protecting any websites not already using the plugin from the vulnerability, but websites already using it were not given any notice of the vulnerability, leaving them vulnerable.

In the present the first problem would likely still largely exist if wasn’t for us making sure that developers and the Plugin Directory are notified when unfixed vulnerabilities are disclosed. The second problem still exists despite it being indicated years ago that a solution would be forth coming, a more recent explanation of why that hasn’t happened doesn’t make sense.

The second problem has recently been a topic of discussion in relation to what has happened to the plugin Contact Form DB, which wordpress.org had recently reported as having 500,000+ active installs. Several weeks ago a persistent cross-site scripting (XSS) vulnerability that existed in the plugin was disclosed. Shortly after that the plugin was removed from the Plugin Directory. At this time the plugin remains out of it, due to the Plugin Directory insisting on further security improvements. While that is the case people have been wondering where it went and then discussing the fact that the current handling of this type of situation leaves people left with no information when something like this happens.

Considering that we suggested letting people have at least a general idea of what is going on years ago, we obviously think giving everyone information on what is going on is a good idea. In the meantime if you are using our service you would already know what is going on, something that would seem to be useful to someone like one of the commenters there, whose comment in part reads:

That would also enable existing users to know that there was a vulnerability and choose to disable or knowingly risk it. As it is now, my agency has hundreds of sites using this plugin and we had no idea there was an issue with it.

One of the ways we keep track of vulnerabilities in WordPress plugins is to monitor the WordPress Support Forums, something we started doing after belated becoming aware of a plugin with intentionally malicious code shortly after we started the service. Through that we became aware of the vulnerability on January 13 and added it to our data on the same day.

Another thing we do as part our service, which others providing vulnerability data on WordPress plugins don’t do, is that we test out each vulnerability, so when the developer released a new version, 2.10.29, that was supposed to fix this, we tested it out. We found that it didn’t fix it, we then updated our data so our customers would know that they were still vulnerable. We also notified the developer of the issue and where in the code the vulnerability still remained (as well as a suggestion for a better fix). A newer version has been submitted to the Plugin Directory that does resolve this, but it currently isn’t available through the normal update mechanism.

For vulnerabilities that haven’t been fixed we are always available to work with our customers to make a determination as to what to do in the meantime. Maybe it is something you can safely ignore, maybe it is something that disabling, but not removing won’t resolve, or maybe we can provide with a workaround (as we could have in this situation).

Other Providers Still Don’t List This Vulnerability

So what if you are relying on another provider of vulnerability data in plugins? You wouldn’t know about this vulnerability. If you get your vulnerability data from another plugin or service it likely uses data from the WPScan Vulnerability Database (the use of their data is not always disclosed) and the vulnerability still isn’t listed in that. That is also true for the plugin CWIS Antivirus Scanner, which uses its own data.

At this point the people behind those could have known about the vulnerability even without doing the extensive monitoring we do, to provide our customers with the best data, as we listed it in our latest monthly post on what was new with the service along with the rest of the vulnerabilities we added last month. That’s a reminder of the lower quality of the data you are going to get if you get your plugin vulnerability data from someone other than us.