For us providing the best data on vulnerabilities in WordPress plugins is important, but we could easily being doing that even if we were doing much less than we do currently, but even with that we continue to work to improve and find ways to gather data on more vulnerabilities. As an example of how far ahead we are, take blog post from today from the security service Detectify.

The post starts out with this:

For continuous coverage, we push out major Detectify security updates every two weeks, keeping our tool up-to-date with new findings, features and improvements sourced from our security researchers and Crowdsource ethical hacker community. Due to confidentially agreements, we cannot publicize all security update releases here but they are immediately added to our scanner and available to all users. This post highlights a few things that we have improved in the last two weeks.

Considering that a vulnerability in a WordPress plugin was widely exploited a day after it was fixed last week, having updates every two weeks is much too slow. By comparison we continuously update our data and when you use our service you website is checked against our data as often as every hour.

It then goes on:

The following are some of the security vulnerabilities reported by Detectify Crowdsource ethical hackers. We added these tests to the Detectify scanner tool on 15 November.

Their service starts at $60 a month (which is much more than ours) and yet they are relying on crowdsourcing to keep up with vulnerabilities, which clearly produces poor results, considering the first vulnerability listed after that is:

WordPress limit-login-attempts XSS
This WordPress plugin logs the IP-address of users that has multiple failed login attempts. However, in place of recording the actual IP-address, it is possible to log the value of the X-Forwarded-For-header instead.

When the administrator of the WordPress installation later logs into the dashboard the log is visible to them without proper filtering. This means that it is possible to use an XSS-payload as header value. Additional reading.

If you follow the link in that post you find it is link to our post about the vulnerability from March 9th. So they are 8 months behind us in detecting this issue in a plugin with 2+ million installs, according to wordpress.org.

Making that worse, at least in their explanation in the blog post, they are missing the important qualification that this vulnerability is only exploitable if you changed one of the plugin’s default settings, so probably most of the websites using this plugin are not currently at any risk. Between March and today we have added numerous vulnerabilities that are much more likely to be a serious security risk, which it would seem they probably don’t have in their data set considering the haven’t mentioned those.

At the end of the post they tout how many vulnerabilities they check for:

Detectify is a continuous web scanner monitor service that can be set up for automated scanning for 1000+ known vulnerabilities including the OWASP Top 10.

Probably not surprisingly considering they are adding something we have had for 8 months, we have significantly more vulnerabilities in our data set and we just are focused on WordPress plugins, while they are supposed to be handling all types of websites so even if there data on WordPress plugin vulnerabilities is shallower they should have more vulnerabilities.