While looking to see if anyone had disclosed a vulnerability in a WordPress plugin we were looking into, we clicked on a Google search result for a competing data source for WordPress plugin vulnerabilities, the WPScan Vulnerability Database. Why Google returned this page as a result is unclear since the page is basically empty:
When we mentioned the web security provider WebARX provider back in March it was in the context of their service providing less protection against a WordPress plugin vulnerability than simply keeping plugins up to date, while they made it seem otherwise. That is a pretty big issue when their service is prominently promoted with the claim that it can “Protect websites from plugin vulnerabilities”, as can be seen on their homepage:
Repeating a frequent recent pattern, once again when looking to see if the discoverer of a vulnerability in a WordPress plugin had put out a report on it we instead found a competing data source for data on vulnerabilities in WordPress plugins, the WPScan Vulnerability Database, claiming a vulnerability had been fixed, when it hadn’t. Compounding that problem, others repeated that claim, as they do with all of WPScan’s data, but without disclosing where the data is coming from or its well known quality control issues. This instance of that also is a good example of where security providers continuously looking to improve what they are doing, instead of continually failing in the same way, helps to improve other parts of what they are doing.
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.
In the past we recommended the data on vulnerabilities in WordPress plugins from the WPScan Vulnerability Database as a good free alternative to our service, as while the quality of data was much lower, it was available for the right price for a lot of websites. More recently things have gotten worse, without a workaround for those relying on their data, so if you need access to this type of data our service is really the only good option.
Right now the people on the WordPress side of things refuse to even discuss making easy changes to help avoid websites being unnecessarily hacked due to plugin vulnerabilities, but if that was ever to change there is plenty more that could be done to improve the security plugins. Based on some checking we have done over the last week looking at the security of plugins quickly growing in popularity could head off issues getting exploited before they become even more popular.
We used to say that the WPScan Vulnerability Database was good source of data on vulnerabilities in WordPress plugin for the price, considering that it is low quality data, but accessible for free. Over time though the quality has gone further down and the people behind it seem to be unconcerned with the truth, with is kind of important when it comes to security.
On Monday we discussed that two of Facebook’s plugins for WordPress contained vulnerabilities due to basic security failures (and mentioned in passing that another is also insecure due to the same type of issue). There attempts to resolve the vulnerabilities continued to show a lack of concern and or understanding of security, at least when it comes to WordPress plugins. It also makes you wonder what the people running the WordPress Plugin Directory are up to since they know these plugins were vulnerable and didn’t make sure they were properly fixed.
When it comes to security journalism, things are not in very good shape, which has a decided negative impact on improving security, whether with WordPress plugins or otherwise. Part of that seems to stem from the fact that many of the people doing security journalism don’t seem to have the skills necessary to do that. As an example of that, take something we ran across earlier this year when we were looking over someone’s Twitter account for more information related to a claim of a vulnerability in a WordPress plugin and ran across this tweet that they had retweeted:
To make sure we are providing customers of our service with the best data on vulnerabilities in WordPress plugins they may be using we do various monitoring. One of the things we do is monitor our websites and third-party data for indications that plugins are being targeted by hackers. That leads to us noticing plenty of up to that point publicly undisclosed vulnerabilities in plugins that hackers probably are already aware of and are likely already targeting. But what also gets pulled in with that frequently are what look to be hackers trying to access malicious files that hackers have placed on other websites that happened to be in the directories of WordPress plugins. What looks to be a recent example of that involved sending a request to: