One of things we focus on with our service is making sure we our providing the best data on WordPress plugin vulnerabilities to our customers. As there a number options out there, we look to see how they compare to make sure we are surpassing that. What we have found so far is that the other options out there really are not in the same league as what we provide (and they don’t provide the other important features that we do). The latest source we ran across seems to be a good example of that.

One of the thing we do be able to provide data on the most vulnerabilities is that we monitor for changes made to plugins that are related to security, which in addition to vulnerabilities and other security fixes can bring up changes made to security plugins. Through that we ran across a new plugin named ThreatPress and its data set of plugin vulnerabilities. A quick check showed several issues, the first being enough to disqualify this source as serious alternative to us at this time.

That issue is that the data set has very few recent vulnerabilities:

While the heading for the data listed is Disclosure Date, the dates for the first couple of entries don’t match the disclosure dates in their references, so either the dates refer to something else (maybe when they added them to their data set) or they are didn’t reference their real source for those for those listings (which seems possible as well for those two entries).

Since their dates are not clear, for comparison purposes we will assume the disclosure dates listed is the same as the month they added them. So far in May we have added 22 vulnerabilities and they added 0. Last month we added 84 (most of them being from a set of plugins we were one of three discoverers of) and they added 2. In March we added 41 and they added 4.

Quantity isn’t everything, but looking at the results most of the vulnerabilities they added are not likely to be exploited and they hadn’t added what is probably the most serious recent vulnerability. That vulnerability also hasn’t been added to other available data sources either, showing that they don’t even take the simply step of monitoring vulnerabilities that we publicly disclose. With them failing to include those, not surprisingly they are also missing the harder to find ones that we are able to spot through our fairly expansive monitoring.

There were a couple of other issues we noticed in a quick check over their data:

Inaccurate Impacted Versions

Like other data source we have seen, they don’t actually determine what the earliest version that is vulnerable while labeling as if they had. For example, for the most recent vulnerability, a reflected cross-site scripting (XSS) vulnerability in Ultimate Form Builder Lite, the listing under the Versions heading is:

Affected In <= 1.3.2
Fixed In <= 1.3.3

As with many vulnerabilities, not all versions below 1.3.3 are actually impacted. In our testing we found it only impacted versions starting with 1.2.0.

Where that type of detail is particularly important is if you are using the data as part of a hack cleanup, as from our experience they often involve websites that haven’t been updated for some time. When relying on other data source you can end up being told that there are vulnerabilities on the website that don’t actually exist in the version being used, which could mislead as to the source of the hack. We also provide an estimate of the likelihood of exploitation, which helps to focus on vulnerabilities that are likely to be the source of the hack (as many vulnerabilities have almost no chance of being exploited on the average website).

More Bug than Vulnerability

The second most recent vulnerability listed is Multiple SQL injection in AccessPress Social Icons, which we wouldn’t consider a vulnerability. If you just looked at their changes made in the version that fixes it there does appear to be a SQL injection vulnerability fixed. But if you actually look into the details, as we did at the time it was disclose you would see that the page where this occurs on is only accessible to those logged in to WordPress with the manage_options capability, which would normally only be Administrators:

add_submenu_page('aps-social', __('Social Icons','accesspress-social-icons'), __('Social Icons','accesspress-social-icons'), 'manage_options', 'aps-social', array($this, 'main_page'));

Administrators would normally be able to almost anything they want, so a SQL injection vulnerability wouldn’t provide them with any access they wouldn’t have. They also would normally be able to edit installed plugins, so they could undo any protection against this type vulnerability as well.

If you were to give a lower level user the manage_options capability they would normally be able to create a new Administrator level user with what they have access to with that capability.

If this was considered a vulnerability it should have been labeled as an authenticated SQL injection vulnerability.

With this issue there also isn’t even a possibility of cross-site request forgery (CSRF) coming in to play, as the plugin checks for a valid nonce before the potentially vulnerable code ran:

if (isset($_GET['action'], $_GET['_wpnonce'], $_GET['si_id']) && wp_verify_nonce($_GET['_wpnonce'], 'aps-edit-nonce')) {
    include('edit-icon-set.php');
} else {