Most times when a WordPress plugin in the Plugin Directory contains a security issue it is due to poor coding, not someone taking intentional action. But last week a case where malicious code had been intentionally added to a plugin occurred. While this isn’t an every day occurrence, it isn’t unheard off, a previous occurrence was discovered in January.

So what happened? On February 18 the first of two pieces of malicious code was added to version 0.9.8.8 of the plugin Custom Content Type Manager. On Tuesday, March 1st, there started to be public discussion of hackings due to the malicious code that had been added to the plugin. By Saturday the people running the Plugin Directory had removed the plugin from the directory, which occurs if they become aware of a security issue in the current version of the plugin, and released a new version, 0.9.9.9, which removed the malicious code.

While allowing malicious code to get into a plugin with 10,000 users is obviously a problem, the Plugin Directory has over 40,000 plugins, so trying to closely monitor them all would be very difficult. The response time also could have been better, but in our experience it wasn’t nearly as bad it can been in getting a security issue fixed.

The public can probably help to improve response times by making sure they notify the people running the Plugin Directory if they encounter a security issue in a plugin (you can also let us know), instead of just posting in the support forum of a plugin.

Needed Improvements

There are a number of other areas where the WordPress folks could improve the process handling security issues (whether intentionally malicious or not), some of which we have pushing them to do for years.

One that would have impacted this situation is to start to warn webmasters when they have plugins installed that are currently removed from the Plugin Directory for security issues. While in this case a fixed version was released relatively quickly, in many cases a fix isn’t quick in coming at all, if ever (that other plugin discovered to contain malicious code in January didn’t receive a fix). So letting webmaster know about the situation could have a major impact on preventing these security issues from being exploited. We first brought this up four years ago, and it has now been three years since there was indication this would be done, but it still hasn’t happened. You can show support for that happening on its WordPress Ideas page. If you are using our service you should be alerted in most cases, considering that we seem to be the ones that are notifying them of many of the plugins that get pulled for security issues.

That brings us to another issue. What we know from monitoring security vulnerabilities in WordPress plugins is that some developers will not respond to a vulnerability until the plugin has been removed from the Plugin Directory. So the sooner the plugin is removed the sooner a fix will be released. Unfortunately the response time when reporting an issue seems to vary and isn’t always good. Last year we wrote about one instance where four days after we had reported a vulnerability that was being exploited the plugin still had not been removed. On Friday we reported a serious security vulnerability we had discovered  in a plugin to them, along with another related vulnerability in the same plugin,  and it wasn’t until yesterday that it was removed.

We Need to Improve As Well

So far our service has been focused mainly on the vast majority of security issues that are not intentional, so this was a good chance to see how we handle this type of situation. So how did we do in this case? We have included the vulnerability in our service since  early Saturday (before the fixed version had been released). We also added it to the list of vulnerabilities with frequently exploitations attempts that is included with the companion plugin yesterday, for those that haven’t signed up for the service. But there were reports of an issue with the plugin five days before that and the malicious code was added to the plugin 2 weeks before hand, so we have a lot of room for improvement. We have already implemented some changes so that we should be aware of similar issues as soon as they becomes public and are looking at ways we might be able to detect the addition of malicious code to plugins in a quicker fashion than that.

If you are relying on a service that is using data from the WPScan Vulnerability Database (which a lot of free plugins do), you results wouldn’t be as good. They only got around to adding the vulnerability yesterday and for some reason they are claiming that version more than or equal to version 0.9.8.8 are vulnerable, despite the fact that the only vulnerable version was 0.9.8.8.