WordPress Plugin Directory’s Security Review Leads to Putting Public At More Risk
Yesterday we announced we have temporarily ended our notifications to the WordPress Plugin Directory when there are plugins with disclosed vulnerabilities in the current version of the plugin that is in the directory, until they put forward concrete plans to resolve two issues. One of those is finally warning people when they are using plugins that have been removed from the Plugin Directory for security issues. While years ago they claimed they were working on doing this, more recently they have claimed that doing so would put people at more risk. It is truly bizarre position to take just considering that many of these vulnerabilities have been publicly disclosed, so hackers would already have easy access to as much or more information than anyone has proposed including when warning webmasters of the issue. Then you have the fact that plenty of these vulnerabilities are not only known to hackers, but being actively exploited before the plugins were removed from the Plugin Directory (we know this because we have reported many of those to the Plugin Directory).
While that is really a black and white issue, when it comes to security many things are not like that. And in many cases actions do have serious unintended consequences that are not obvious. For example, we wouldn’t have though that the Plugin Directory doing a security review of a plugin after it has been removed for a security vulnerability could lead to putting the public at more risk, but that turned out to be the case as we recently found.
When it comes to suggesting how to improving the handling of security issues with WordPress plugins one of the problems we have found is that things on the WordPress side of things are very opaque. For example, we know they have the ability to release new versions of plugins with a fix when the developer doesn’t do it, but we have found no explanation of what the criteria for doing that are. It looks like the main criteria may be a vulnerability getting press coverage, as that seems to be main difference between the one vulnerability we have seen do that with since the beginning of last year and several other nearly identical vulnerabilities that were all being exploited widely. If we knew what the criteria were we could suggest a change to make sure those plugins actually get fixed. About the only thing they do provide clear information on is what is required to have an update forced out.
Another issue we can’t find any information on is the security review that is done before a plugin removed from the Plugin Directory due to a security issue is returned to it (if you are aware of where that information can be found please let us know). We know these reviews are done from looking at changes made to plugins and some things we have heard from developers, but beyond that it is a mystery.
What we do know though is that they have or cause a number of problems. Far too often we have found that plugins have returned to the Plugin Directory without the vulnerability that caused them to be removed being fixed. In some cases other security changes have been made in response to a request from the Plugin Directory, so there clearly was a review, but one that didn’t accomplish what seems like its most important goal.
The review also slows down a fixed version being released, which seems like it might be a reasonable trade-off if the reviews insured the vulnerability was fixed, but it doesn’t. In some cases where the vulnerability has actually been fixed, but the review brought up other issues that were required to be resolved before the plugin returns. In some cases though the additional issues are not significant, so people remain at risk of the most serious issue for an extended period of time.
Another issue that we see happening, though we don’t have a good idea of how often it is occurring, is that developers decide to abandon the plugin due to this review process. On the one hand if the developer isn’t willing to properly handle security of their plugin, this might not be the worst thing, though with WordPress not warning people about vulnerable plugins it does leave a less than desirable situation. But what if that actually caused public to be at more risk? Well that actually has happened.
Back in January a persistent cross-site scripting (XSS) vulnerability was disclosed in the plugin Contact Form DB, which according to wordpress.org had 500,000+ active installs at the time. That plugin saves contact form submissions submitted through various contact form plugins, including Contact Form 7. After the developers interaction with the Plugin Directory team over improving the security of the plugin they decided to no longer list it in the Plugin Directory. As we noted at the time, the developer wasn’t entirely accurate in describing the situation, as their original attempt to fix the vulnerability had not actually resolved it as the claimed (we had contacted them privately to information of that, but never heard back), so it isn’t clear how much the plugin not returning to the Plugin Directory was on the WordPress side.
Whatever the case there, one of the end results is that many people using the plugin are still using an insecure version of the plugin. As far as we can tell other providers of vulnerability data for WordPress plugins still don’t list this vulnerability in their data (which speaks to the higher quality of our data), so even if someone is taking the extra step of using some product or services, other than ours, that warns of vulnerabilities in plugins they are unlikely to know about this.
Another end result is that other plugins started to gain popularity and new plugins were introduced.
Looking the chart of downloads of the plugin Save Contact Form 7 you can see the impact of the other plugin’s removal (please note the chart counts updating existing installations as downloads as well as new installs):
There is an immediate spike after Contact Form DB was removed. There is then a big spike in late February after an update was released. A lot of those downloads are people that stuck with the plugin, as it went from having 1,000+ active install in December to 4,000+ in February to the current 10,000+.
Going back to the chart you can see that the downloads drop to 0 at the beginning of March, which we would guess was caused by the plugin being removed for a security issue. After version 2.0 was released, which was listed in the changelog as a “Security update.” we tried to figure out if there was a vulnerability fixed and spotted a fix for SQL injection vulnerability in that version.
Also worth mentioning here, according to the stats on wordpress.org even a month after 2.0 was released less than half the installs are using that version:
When we were looking over that SQL injection vulnerability we found a much more serious issue in the relevant code, it turns out that all the contact form submissions saved by the plugin are publicly accessible. More than a month after we contact the developer about the issue we have not heard back from them and the vulnerability remains.
With the ease of exploitation that is something that we believe is more of an issue that the vulnerability that lead to Contact Form DB being removed from the Plugin Directory or what sounds like the issues that were causing the Plugin Directory team to not return it to the directory. Based on the downloads chart it is pretty clear then that the security review has led to a lot more websites using this plugin and putting many more contact form submissions at risk of disclosure.
After discovering that vulnerability we looked over similar plugins and found that another had more limited version of this. The plugin Contact Form 7 Database allows anyone logged in to WordPress to view any contact form submissions saved by that plugin. On a lot of website that isn’t much of an issue, but if account creation is widely available on website, say if it, like our website, use WooCommerce, it could be more serious. When we contacted company behind the plugin more than a month ago about the issue they responded “Our developers working to fix it”, but so far it hasn’t been fixed.
That plugin was only introduced to the Plugin Directory in the middle of March, but it already has 3,000+ active installs.
Like Save Contact Form 7, that isn’t the only vulnerability has recently been discovered in the plugin. After running across a report of a persistent cross-site scripting (XSS) vulnerability (that report used to exist here, but has been removed), we found a reflected cross-site scripting (XSS) vulnerability and cross-site request forgery (CSRF)/form submission deletion vulnerability in the plugin. Those were eventually fixed.