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:

Hi

I wonder will there be any update on the information on the WPScan database? For example, submitting proofs to WPScan saying that the plugin is safe? Currently, it is quite annoying for me to ignore the warning of every sites. I believe this warning also affect other JTRT users and future comers.

Thank you

For some reason that person expect the developer of the plugin to be the one to take the initiative to correct that information, despite them having nothing to do with it.

Then you had someone from the data source respond, again expecting the developer to take the initiative:

Hi,

Ryan here from wpvulndb, can you confirm the version the vulnerability was fixed in, please? We can then add this information to wpvulndb.

Thanks!

It would have been incredibly easy for that person to check on this themself since the vulnerable code involved this line of code:

$getTableId = $_POST['tableId'];

And in the version after the version listed as being vulnerable in the original report it was secured this way:

$getTableId = (int)$_POST['tableId'];

That occurred on November 4, 2017, which was 8 days before it was added to the WPScan Vulnerabilities Database’s data. We have had that in our data set since before it was fixed and then added to their data set, while managing to never falsely claim it was not fixed or require the developer to do anything to make sure that our customers were getting accurate information.

Unfixed Vulnerability

There is another problem indicated by that, the people behind that data source are relying on the developer stating that they fixed vulnerabilities instead of checking on them themselves, when they should well know there is a good chance the developer might be wrong. That isn’t a hypothetical issue, just the other day they again falsely claimed an unfixed vulnerability was fixed. This time with a vulnerability in the plugin Event Monster (Event Management Tickets Booking By Event Monster)disclosed by Admavidhya N. Their report makes no clear statement about whether the vulnerability had been fixed. They did state that versions “1.0.5 and possibly below” are affected. One of the changelog entries for the next version indicates a vulnerability (which matches this one) was fixed:

Bug Fix: vulnerability fix in registreation form

If you are relying on the WPScan Vulnerability Database for information on vulnerabilities in WordPress plugins you would have been led to believe it had been fixed:

We actually test things out though and we found that vulnerability hadn’t been fixed in that version. At first we were a bit confused since in looking at the changes made in version 1.0.6 it looked like it had been fixed, but that is why doing the testing is important because it easy to miss things. Especially in an instance like this, where the discoverer doesn’t appear to have figured out what the underlying code causing the issue was.

Through a bit of further checking what we realized is that there actually two files that had the code that needed to be secured, but only one of them had been fixed. So, as of the most recent version, in the file /event-monster-output.php the relevant user input is sanitized:

217
218
219
220

$em_attendee_first_name = sanitize_text_field($_POST['form-first-name']);
$em_attendee_last_name = sanitize_text_field($_POST['form-last-name']);
$em_attendee_email = sanitize_email($_POST['form-email']);
$em_attendee_phone = sanitize_text_field($_POST['form-phone']);

But that doesn’t occur with otherwise identical code in the file /event-monster-single-output.php, which is the one the proof of concept in the report on the vulnerability causes to run:

24
25
26
27

$em_attendee_first_name = $_POST['form-first-name'];
$em_attendee_last_name = $_POST['form-last-name'];
$em_attendee_email = $_POST['form-email'];
$em_attendee_phone = $_POST['form-phone'];

We have notified the developer of that.

This sort of thing makes WPScan Vulnerability Database of limited use, since you need to double check any vulnerabilities they state have been in plugins you use to be sure they are actually fixed and how many people have the necessary expertise to do that. Making that worse their data set is rather limited, so often you wouldn’t even know that you should be double checking a vulnerability report about a plugin you are using, by comparison with our service we manage to have a much more complete data set, while doing the checking for you.