5 Jul 2019

Sucuri, WPScan, and Others Incorrectly Claim Persistent XSS Vulnerability in WordPress Plugin with 500,000+ Installs Has Been Fixed

Two days ago the web security company Sucuri disclosed a vulnerability in the very popular WordPress plugin, WP Statistics, which has 500,000+ active installations, and claimed it had been fixed. The post is fairly hard to follow and seems to mostly make a case that firewalls can introduce additional security risk, which is odd argument for a provider of a firewall to make.

Considering Sucuri’s recent track record of getting basic details wrong when it comes to WordPress plugin vulnerabilities, including claiming that vulnerability existed that didn’t and trashing a developer falsely, you can’t take their claims at face value. There post makes it hard to follow what exactly the issue is, but more importantly it neither provides a proof of concept or provides an explanation of how the vulnerability was supposed to have been fixed, so without doing additional work it isn’t possible to confirm if what they claimed is correct. [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]

14 Feb 2019

WPCampus and Paul Gilzow Spreading False Information About Claimed Vulnerabilities in WordPress Plugins

One of the striking and telling aspects of the security community that seems to go a long way to explaining why security, whether of WordPress websites or more broadly, is in such bad shape is the lack of concern for providing accurate information. We often find that security companies are telling outright lies (or they are so unfamiliar with the basics of security that they have no idea that they are not telling the truth and shouldn’t be in the security industry). When it comes to security researchers, security professionals, or security journalists we have recently found over and over an apparent complete lack of concern that they might be providing information that isn’t accurate and lack of understanding why that others might take issue with that. That leads to a situation like if you tried to build the foundation of a home on quicksand, as can be seen by news coverage of security breach after security breach.

Along those lines we had recently tried to leave comments to point out that information on WordPress plugin vulnerabilities put out in posts on the website WPCampus and written by Paul Gilzow, who is described as a “Web application security and accessibility evangelist. Software instructor. Conference lecturer and presenter.”, is not accurate. While WPCampus’ code of conduct shown in the footer of their website states “All participants should be able to engage in productive dialogue. “, they don’t seem to be interested in a dialogue at all, as our comments haven’t been shown and the issues raised have not been resolved. [Read more]

1 Oct 2018

It’s No Wonder Security Is In Such Bad Shape When the Security Community Doesn’t Understand the Basics of Vulnerability Types

One of the things that you get when using our data on vulnerabilities in WordPress plugins either through our long time service or our new newsletters instead of trying to do things on your own or using lower quality data sources, is that we actually check over the reports and provide an accurate information on them. For a fair amount of reports the original discloser has provided inaccurate information about the vulnerability (or there isn’t even a vulnerability).

One area we see a lot of confusion, whether it be with members of the security community or hackers is with arbitrary file viewing and local file inclusion (LFI) vulnerabilities. A recent example where things got quite mixed up and where other data sources would have lead you astray involved two vulnerabilities disclosed by Manuel Garcia Cardenas a couple of weeks ago. [Read more]

10 May 2018

How Free Data Sources for WordPress Plugin Vulnerabilities Compare To Us with Possibly Targeted Vulnerable Plugin

One of the reasons why security is in such bad shape despite the enormous amount of money spent on it is that there is a failed market when it comes to security products and services. In simple terms it isn’t currently possible for consumers to make well informed decisions between different products and services due to rampant falsehoods and outright lies about them as well as a lack of watchdogs to limit those or independent entities that provides accurate information needed to be able to make informed decisions. What sticks out to us is how widespread these falsehoods and outright lies are. We often see them in just the somewhat obscure area we deal in, data on vulnerabilities in WordPress plugins.

Just last week we discussed how the makers of the very popular WordPress security plugin, Wordfence Security, were lying by claiming that the data source they use is “official” and only contains “confirmed/validated” vulnerabilities. In reality neither of those claims is true, there is no official source of WordPress plugin vulnerability data and their data source doesn’t actually confirm or validate vulnerabilities before including them. What they didn’t mention nor are we aware of them disclosing elsewhere is what the data source used is, which is the WPScan Vulnerability Database. They are hardly alone in using that source and they are certainly not alone in not being upfront about using that data source, which is its own problem because we have seen people believe that multiple organizations were confirming a vulnerability when all of them were simply repeating an unconfirmed claim from that data source. [Read more]

18 Dec 2017

Lack of Due Diligence by the WPScan Vulnerability Database and WPCampus Lead to False Claim That WordPress Plugin Vulnerability Was Fixed

We are big believers in having the full details of vulnerabilities, whether they are in WordPress plugins or other software, be disclosed in most instances. That isn’t because that makes our work of compiling data on ones in WordPress plugins easier, but because we see the positive impact that has, as well as the more often emphasized negative impact. One of the important reasons for doing that is that we often find vulnerabilities that were supposed to have been fixed have only been partially fixed or not fixed at all. With more details it makes it easier for others to check to make sure the vulnerability has been fully fixed.

What is important to keep in mind though is that just releasing those details doesn’t mean that they will be checked and any unfixed vulnerabilities will be caught. When it comes to WordPress plugins, that is one of quite a few things that we seem to be the only ones doing. You wouldn’t know that by claims that people make about us, for example in a recent review of the companion for a plugin, which was less a review of the plugin and more someone just bashing us, they wrote: [Read more]

3 Nov 2017

Not Really a WordPress Plugin Vulnerability – Week of November 3, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Full Path Disclosure in Inline Image Upload for BBPress

At the end of September we mentioned that the website WPCampus wasn’t properly crediting us when discussing things we had written, but it isn’t just us that is true with us. Last week in their post on plugin vulnerabilities they credited Wordfence for discovering a vulnerability, but for the other claimed issue they discussed they left out any mention of the discoverer: [Read more]

1 Nov 2017

Vulnerability Details: Reflected Cross-Site Scripting (XSS) Vulnerability in Pretty Links (Lite)

Earlier today we posted the details of a reflected cross-site scripting (XSS) vulnerability in the plugin Pretty Links (Lite) that was somewhat vaguely disclosed by Detectify about a month ago. Shortly after that had been disclosed the website WPCampus had included reference to that in their weekly spreadsheet of vulnerabilities in WordPress, though they pointed to information on a possible different reflected XSS vulnerability in the plugin. It isn’t clear if they were aware that was a different vulnerability than the one mentioned by Detectify (as that one involved the input “message”) or if they have notified the developer of that issue.


[Read more]

13 Oct 2017

Not Really a WordPress Plugin Vulnerability – Week of October 13, 2017

In reviewing reports of vulnerabilities in WordPress plugins we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we have been releasing posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. We have been thinking that providing information on why those are not included in our service’s data could be useful, so we are trying out putting a weekly post when that occurs detailing those issues.

Directory Traversal Vulnerability in WP Smush

There recently was a report of a directory traversal vulnerability in WP Smush. If you believed the developers (who are also the developer of a security plugin) this is a vulnerability, the changelog for version 2.7.6 is: [Read more]

28 Sep 2017

WPCampus Failing to Credit Us and Spreading Inaccurate Information on WordPress Plugin Vulnerabilities

One of the many issues we have noticed when it comes to information on WordPress security you can find on the web is that often the original source of information is not being credited in articles written about issues. We have seen plenty of that happen not just to us, but to many others as well. That credit can be an important reward for doing things like discovering new vulnerabilities, which otherwise have little return. Another issue that comes with that is that we frequently see that the subsequent articles have inaccuracies, sometimes major, which without the possibility of seeing the original are more likely to be repeated subsequently.

As example of where that credit can have an impact, we recently had someone sign up for a free trial of service that originally came to our website from the page Vulnerable WordPress Plugins Report for the Week of September 1, 2017 on the WPCampus website. [Read more]