Recently we looked at two instances where the WPScan Vulnerability Database only included some of sets of vulnerable plugins that we had disclosed, leaving those relying on their data unaware that they were using plugins with known vulnerabilities in the current versions. One set of vulnerabilities were easily exploitable and the other set involved plugins that it looked like hackers were already targeting, so the omissions were pretty serious. We still don’t understand how that happened, seeing as it is much easier for the WPScan Vulnerability Database to add new vulnerabilities than it for us since they don’t review the vulnerabilities before adding them. Their lack of reviewing vulnerabilities causes its own issues, as we found in two cases where they were claiming that vulnerabilities were fixed when they were not. If it were not for us, those vulnerabilities would still be in the plugins at this point, which is a reminder of the critical role we play in the security of WordPress ecosystem.

Bad Report = Bad Fix

Recently a report of a vulnerability in the very popular NextGEN Gallery plugin, which has 1+ million active installs according to wordpress.org, was released. We continue to be unsure of what vulnerability the report was actually trying to refer to since in only a few sentences it seems to be referring to an authenticated local file inclusion (LFI), authenticated arbitrary file viewing, or authenticated remote code execution (RCE) vulnerability. The WPScan Vulnerability Database list the vulnerability as being an authenticated local file inclusion vulnerability:

But in our testing we couldn’t find where that or an authenticated arbitrary file viewing vulnerability would have existed in the relevant code. Whether either of those vulnerabilities existed it seems to us that the vulnerability definitely existed, the authenticated remote code execution vulnerability, was the most serious, since it would allow you to do the equivalent of both other vulnerabilities.

In the version that reporter of the vulnerability and the WPScan Vulnerability Database reported it to be fixed, it wasn’t. The developer had made a change in that version that would have been relevant for either a local file inclusion or arbitrary file viewing vulnerability (though the code that already existed had same impact on the possibility of an arbitrary file viewing vulnerability). After we notified the developer, a change was made to try fix the actual vulnerability, but the first attempt included a security check that was easily bypassed. After notifying them of that and suggesting a more secure way to accomplish that, the vulnerability was finally fixed in version 2.1.60.

Fixed and Fixed Again

The second vulnerability also involves a bit of confusion. While the report of a vulnerability in the Check Email plugin labels the vulnerability as a cross-site scripting (XSS) vulnerability, parts of the report claimed the issue was caused by a cross-site request forgery (CSRF) issue. In version 0.5 of the plugin, protection against CSRF was put in place for the sending of test emails, but this protection didn’t do anything for the XSS issue because that can occur without any attempt to send a test email. After noticing the issue we contacted the developer and after one additional release, 0.5.1, that didn’t fix the issue, we were able to work with them to get a proper fix to the issue put in place with version 0.5.2.

As of November 15 the WPScan Vulnerability Database listed the vulnerability as being fixed in version 0.5:

A week later it was supposed to have been fixed 0.5.1:

You Need To Double Check Their Data

If you are using data from the WPScan Vulnerability Database and you actually want to be sure that vulnerabilities in plugins you use have been fixed you will need to test out any relevant vulnerabilities yourself, or you could sign up for our service, where we actually do the testing when adding vulnerabilities to our data (there are a number of other advantages that come with our data).