When it comes to data on vulnerabilites in WordPress plugins, at this time you really only have two choices our data or the data from the WPScan Vulnerability Database. We think that WPScan’s data is a good option for a lot of websites since it can had for free, but for websites that can afford to spend money on the security of the websites using their data comes with some significant limitations. A couple of weeks ago we looked at an example of one of those, we found that with related arbitrary file upload vulnerabilites in four plugins we had disclosed they had only included one of them. Considering that type of vulnerability is likely to be exploited and that two of the plugins they didn’t include listings for had not been fixed, so doing the basic security of keeping your plugins up to date would not have protected you, that was a pretty big issue. By comparison we had included all of them in our data at the time we disclosed them.

The source of our discovery of those vulnerabilites also is a big difference between the data sources, our data isn’t just compilation of third-party data on vulnerabilites like WPScan’s. One of the other sources of vulnerabilites in our data set is vulnerabilities we find based on monitoring what plugins hackers are targeting. Sometimes it is obvious from that what vulnerability they are targeting, but in other cases we only see that them probing for usage of the plugin, but not what they would target if it existed. The four vulnerabilites mentioned earlier came from that.

Through that monitoring we recently saw a hacker probing for usage of six plugins. Unlike most cases where we are pretty sure we found the vulnerability the hacker would be targeting, this time we are not sure if the vulnerabilities we found are the ones being targeted. Last Monday we disclosed vulnerabilites in five of the plugins (and mentioned they may be other security issues). For the sixth plugin the vulnerability we spotted while trying to figure out what might have been the connection between the plugins had already been disclosed more that two years, but must never have been reported the wordpress.org Plugin Directory as the plugin still remained there until the time we notified the people running it.

The next day the WPScan Vulnerability Database added the persistent cross-site scripting (XSS) vulnerability in WordPress Appointment Schedule Booking System to their data (incorrectly labeling it as being an authenticated vulnerability though). The other four vulnerabilities that we disclosed at the same time have not been added (the previously disclosed vulnerability was already in their data).

In the previous instance we couldn’t see anything that might explain why the vulnerability they did add was included and the others were not. That is also the case in this instance. The vulnerability they included didn’t have the most active installs, it was tied for second with 400+, while another had 1,000+. It also wasn’t the type of vulnerability as there were two other persistent XSS vulnerabilites disclosed. It wasn’t a combination of the active installs and type, as the other 400+ active installs vulnerability was also had the same type of vulnerability.

While missing vulnerabilites is a pretty significant issue, as long as WordPress chooses to leave the public in the dark about plugins they know contain vulnerabilites in their most recent version even if you don’t get notified about all of the vulnerabilites being disclosed, using the WPScan data will provide additional protection over keeping your plugins up to date. But if you want the best data when it comes to that signing up for our service provides you that. We also include vulnerabilites that we see being exploited in the companion plugin for the service, so installing that even if you have yet to sign up for the service, will provide protection over and above keeping your plugins up to date. Security plugins on the other hand will provide you little in the way of protection as can be seen in our recent tests of them against vulnerabilites in plugins.