One of the problems we have found with selling a service that provides data on vulnerabilities on WordPress plugins is how many entities are out there that are putting out free, but highly inaccurate information on them, where they present things in a way that would indicate that they are professionals providing accurate information. If people believe they can get high quality data for free, it isn’t hard to believe they are going to be less inclined to pay for it, though for those that could afford and need accurate data, getting misled is major downside of this for them as well as us. We just ran across another source providing vulnerability data on WordPress plugins, Cybersecurity Help, and the entry that led to us running across them while looking for something else, shows what we have long seen.
If you look at their entry for a vulnerability in the plugin Register IPs it looks professional:
But information is obviously wrong. For example, they list these versions as being vulnerable:
- Register IPs 1.8.0
- Register IPs 1.7.1
- Register IPs 1.7
- Register IPs 1.6.1
- Register IPs 1.6
But the vulnerability only existed in a single version of the plugin. So where did those versions they listed come from? Well one possibility is that they just assumed all of the previous versions were vulnerable and listed the versions that show up under Previous Versions heading on the plugin’s page on the WordPress Plugin Directory (those are not in fact all the previous versions though):
The belief that all previous versions were vulnerable in turn might be because they copied data from another data source, the WPScan Vulnerability Database, which doesn’t accurately list which versions are impacted either:
Another big problem is that they inaccurately describe the vulnerability. While as we detailed for our customers this is a persistent cross-site scripting (XSS) vulnerability, they are describing it as reflected XSS vulnerability and for some reason only refer to it as an cross-site scripting (XSS) vulnerability:
The disclosed vulnerability allows a remote attacker to perform cross-site scripting (XSS) attacks.
The vulnerability exists due to insufficient sanitization of user-supplied data passed via HTTP headers. A remote attacker can trick the victim to follow a specially crafted link and execute arbitrary HTML and script code in user’s browser in context of vulnerable website.
It isn’t a great sign that they don’t seem to have a basic understanding of the name of various types of cross-site scripting (XSS) vulnerabilities. That isn’t pedantic issue, the type of cross-site scripting (XSS) vulnerability actually matters a lot, since reflected cross-site scripting (XSS) vulnerabilities are of much less of concern than persistent cross-site scripting (XSS) vulnerabilities. Something that would seem important for a company, like this one, which is providing a vulnerability scanner, to understand.
This isn’t a one off issue, they also have another recent entry that repeats the false claims from the WPScan Vulnerability Database of there having been a couple of vulnerabilities in a plugin with 1+ million installs. In fact, it looks like this data source, like plenty of others, is copying data from WPScan’s data, which is already of low quality, and then in this case, adding their own additional inaccuracies on top of that.