Login

Tag Archives: WPScan Vulnerability Database

25 Jun 2019

Other Vulnerability Data Sources Miss That a Reflected XSS Vulnerability in Custom 404 Pro Hasn’t Been Fixed

Being warned about vulnerabilities in WordPress plugins you use isn’t much good if you are being told that vulnerabilities have been fixed when it hasn’t. That is often a problem with data sources on vulnerabilities in WordPress plugins other than the one what underlies our service.

Yesterday an update to the plugin Custom 404 Pro had the changelog entry “Fix Reflected XSS”. In looking to see if the discoverer of that had put a report we found multiple places reporting that a vulnerability had been fixed. [Read more]

19 Jun 2019

WPScan Vulnerability Database Is Misleading Users of Plugin With 200,000+ Installs About Its Security

We used to say that the WPScan Vulnerability Database was good source of data on vulnerabilities in WordPress plugin for the price, considering that it is low quality data, but accessible for free. Over time though the quality has gone further down and the people behind it seem to be unconcerned with the truth, with is kind of important when it comes to security.

For a reason that doesn’t make sense to us they refuse to credit us for vulnerabilities we find and instead belatedly add some of them citing another source. That creates an unneeded problems for those relying on their data, which could be leading to websites being hacked. [Read more]

7 Jun 2019

WPScan Vulnerability Database Leaving Those Relying on It Unaware of “Vulnerability” in Plugin With 500,000+ Installs

When it comes to getting data on vulnerabilities in WordPress plugins what we have noticed is that many sources are not using unique data, but instead reusing data from another source, often without letting people know what the true source is and never with a disclaimer about the quality issues that are inherent in that data source. That source is the WPScan Vulnerability Database, but recently we realized that they in fact are often just copying their data from yet another source. That source being the Common Vulnerabilities and Exposures (CVE) system. As we have more closely monitored that source recently we have noticed plenty of issues with it. This week we noticed something that wasn’t as much concern, but does present a worse picture of the WPScan Vulnerability Database.

Earlier this week CVE-2019-12566 was published, which involves a claimed stored XSS vulnerability in WP Statistics, which has 500,000+ installs according to wordpress.org. The summary for that is: [Read more]

29 May 2019

We Actually Test Out WordPress Plugin Vulnerabilities, So We Don’t Falsely Claim They are Fixed like the WPScan Vulnerability Database Does

Recently we have had a number of instances where developers of WordPress plugins incorrectly claimed that we had falsely claimed there was vulnerability in the most recent version of their plugins. Since we are well aware of what kind of problems that getting that wrong cause, we are very careful with what we do and say, so it would be very difficult for us to make a false claim like that. Others seemingly are not concerned about doing the same, so for example, another data source, the WPScan Vulnerability Database is claiming a vulnerability that had been in the plugin JTRT Responsive Tables hasn’t been fixed, despite that having been fixed before they even added it to their data set and despite it being fixed over a year and half ago. That is something we ran across recently in our monitoring of the WordPress Support Forum for information on vulnerabilities in plugins that our not already in the data set for our service.

Reading the topic in question you get a bit of an idea of the unnecessary problems that data source causes. One of the messages in it reads: [Read more]

23 May 2019

WPScan Vulnerability Database Lacks Data on Majority of Vulnerabilities We Saw Exploit Attempts For a Week Ago

In a previous post today we noted how our service can be useful for figuring out how WordPress websites have been hacked. It obviously would be better to avoid being hacked in the first place and our service also helps with that, but there are limits to that. If hackers are the first to find vulnerabilities then we are going to only be able to notify our customers after that, though we may be able to notify them before the vulnerability can be exploited on their particular websites. With other data sources, the results of even being able to provide information after the fact is limited, as can be seen with the very popular, despite being of rather poor quality, WPScan Vulnerability Database.

Last Thursday we saw what looked to be hackers probing for usage of five plugin on our website. Two of them had recently disclosed persistent cross-site scripting (XSS) vulnerabilities discovered by Sucuri, which likely was what led to hackers probing to see if websites were using the plugins. Even now WPScan’s data is missing one of those vulnerabilities (or a still unfixed vulnerability in the same plugin), for the other they added it on Friday: [Read more]

13 May 2019

WPScan Vulnerability Database Spreads Easily Checkable False Claims of Vulnerabilities in W3 Total Cache

W3 Total Cache is one of the most popular plugins in the WordPress’ Plugin Directory, with 1+ million active installations according to wordpress.org. Last week a new version was released where one of the changelog entries is “Improved security on calls to opcache flush”. Notable it didn’t claim that any vulnerabilities were fixed in that, but if you were relying on other data sources on vulnerabilities in WordPress plugins you were told that there were two ones fixed related to that change, which clearly shows that these other data sources don’t actually confirm or validate claimed vulnerabilities before adding to their data set.

The main culprit for that situation was the WPScan Vulnerability Database which was the source others like WPCampus and ThreatPress then copied their data from. [Read more]

10 May 2019

While Others Mislabel a Possible Vulnerability, We Find a Vulnerability in Custom Field Suite

The changelog for the latest version of the WordPress plugin Ultimate FAQ is “Fixes a minor possible XSS issue”, we don’t know where the possible part comes from since that fixes a vulnerability and when we contacted the developer about that vulnerability we offered to provide them a proof of concept that confirmed that vulnerability was in fact exploitable. Vulnerabilities being inaccurately referred to as a possible or potential vulnerability isn’t an uncommon issue. By comparison the changelog for the latest version of Custom Field Suite is “Fix: prevent possible XSS for logged-in editors or admins (props reddy.io)” and what was fixed there would actually be a described as a possible vulnerability, since it involves allowing those users to do something they normally are permitted to do anyway due to them normally having the “unfiltered_html” capability.

Unfortunately, unlike us, other data sources don’t seem to care much for accuracy as that was added to the CVE’s data without that important qualifier: [Read more]

6 May 2019

What Plugin Vulnerabilities Was Up to in April

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service. Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during April (and what you have been missing out on if you haven’t signed up yet).

Paid customers of the service can suggest and vote on plugins to have a security review done by us (you can also order a review separately). This month we released details of our review of Shareaholic. [Read more]

2 May 2019

Did Sucuri Lie About a Claimed SQL Injection Vulnerability or Unnecessarily Frighten People Due to Not Doing Basic Testing?

Yesterday we wrote about the web security company Sucuri overstating the impact of a SQL injection vulnerability, which they had re-discovered a year and half after we had discussed it. That was one of two claimed SQL injection vulnerabilities they disclosed recently and the post on the other, claimed to be in the plugin Advance Contact Form 7 DB, manages to be worse.

Their post starts by making a claim that doesn’t seem to make sense: [Read more]

29 Apr 2019

WPScan Vulnerability Database Admits to Intentionally Not Warning About WordPress Plugin Vulnerabilities They Know About

Last Tuesday we disclosed an arbitrary file upload vulnerability in the plugin WooCommerce Checkout Manager caught through our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities, so not surprisingly the customers of our service were also warned about it then. On Thursday we noted on Twitter that we had seen probing for usage of the plugin that was likely coming from hackers. If you were relying some other product or service to let you know about vulnerable WordPress plugins you likely were late in getting notified of that, since many of those use data from the WPScan Vulnerability Database. When it was belated added to their data set on Friday a couple of things stuck out to us, one being that we were not listed as a reference:

[Read more]