Back in 2012, years before we started this service we noticed a couple of big problems with how security issues in WordPress plugins were being handled. The first one was that there were many vulnerabilities that existed in the current versions of plugins that had been publicly disclosed, but the plugin remained available in the Plugin Directory. The second was that when a vulnerability in a plugin was reported to the Plugin Directory the plugin was removed from it, protecting any websites not already using the plugin from the vulnerability, but websites already using it were not given any notice of the vulnerability, leaving them vulnerable.
Yesterday we discussed a couple of recent instances where WordPress plugins were reported to have vulnerabilities that were fixed by discovered and those vulnerabilities were added to WPScan Vulnerability Database with the vulnerabilities listed as be fixed. But in both cases when we actually tested out the vulnerabilities as part of our adding them to our own vulnerability data, we found that the vulnerabilities had not actually been fixed. Those instances were a reminder of the need to actual check if vulnerabilities have actually been fixed (those two instances are by no means the only times that has happened) and reminder that isn’t something that happens with data included in the WPScan Vulnerability Database, which is used in a number of services and plugins. It turns out they were not the only ones that incorrectly listed one of the vulnerabilities as being fixed.
One of the things we state about our service is that we provide our customers with the best data on vulnerabilities in WordPress plugins. To show an example what difference that makes let look at a recently created plugin that also provides data on plugin vulnerabilities.