When it comes to data on vulnerabilities in WordPress plugins, what we have seen is that data sources other than us are often not doing basic verification. At its most serious, that leaves people thinking that they are using a secured version of a plugin, while still being vulnerable. If those data sources and others that reuse their data were upfront about that, it would be problematic, but they don’t even do that.

Take the Patchstack Vulnerability Database, which has replaced the WPScan Vulnerability Database in a lot of places once the latter source started limiting free access. It is marketed with the claim that it is:

Hand curated, verified and enriched WordPress vulnerability information

Beyond the hipster element of that, it isn’t actually true.

Take this entry from just yesterday:

The claim there is that an arbitrary post deletion vulnerability existed in version 3.1.23 and below of the plugin WP DSGVO Tools (GDPR).

One starting point for verifying that vulnerability existed and what version it was fixed in would be to try to exploit the vulnerability in the last version claimed to be vulnerable, 3.1.23. We did exactly that when we were checking over the original report from Wordfence about this. It didn’t work.

The explanation for why it wouldn’t could be seen if you took another approach to verifying this, looking at the relevant code. What you see when you do that is code doesn’t make sense as of 3.1.23:

7
8
9
10
11
12
13

protected function run(){
    $id = $this->get('id');
    if (is_numeric()) {
        wp_delete_post( $id );
    }
    die();
}

Before doing the arbitrary post deletion, it is checked if the is_numeric() function is true. It will always be false. What the developer must have intended is to check if the variable $id was numeric.

Patchstack were not the only ones who got this wrong. The aforementioned WPScan also made the same claim:

It appears in both cases they simply repeated the claim from Wordfence:

Which curiously claims to have discovered the vulnerability on September 27, but the code had been in that broken form since September 22.

Looking at other recent reports in their database, doesn’t indicate that their handling is different for other reports. To the extent the are trying to “enrich” the data, it isn’t producing a good result.

How Are they Testing Firewall Rules?

With both Wordfence and Patchstack, you would expect that they would have tested out exploiting the vulnerability since they claim to write firewall rules to protect against specific vulnerabilities (Patchstack misleadingly calls these virtual patches). You would want to test things to make sure your rules actually work.

While Wordfence wrote a rule to protect against this specific instance of arbitrary post deletion, using this vulnerability, we implemented general protection against this type of vulnerability that will be in the next release of our Plugin Vulnerabilities Firewall plugin. Based on our automated testing of WordPress firewall plugins, it looks like no other firewall plugin currently provides that by default. NinjaFirewall has that type of protection, but it is disabled by default.

Making Sure Vulnerabilities Have Been Fixed

The problem caused in this situation is limited since there really had been a vulnerability and it was really fixed, but in other situations relying on those providers is going to lead you to using plugins you should know are still vulnerable. The solution would either be to test out vulnerabilities yourself, which is going to be hard for most people to do, or to rely on a data provider, like us, that does that work. In this situation, none of those entities has provided a proof of concept, making testing this yourself even harder (if they had created a proof of concept, they should have noticed that the vulnerability didn’t work in 3.1.23).

Plugin Security Scorecard Grade for Patchstack

See issues causing the plugin to get less than A+ grade