A Third of The WordPress Plugin Directory Team Works for Matt Mullenweg, Which is a Big Problem
Last week we ran across information we had been wondering about for some time for one specific reason, but found the information important for other reasons. We had wondered for some time who were the people doing the security reviews of WordPress plugins before they returned to Plugin Directory after being pulled for security issues. As we have mentioned in the past, the reviews have not been very good, the most glaring issue being a failure to make sure that vulnerabilities that had lead to plugins being removed had been fixed when they likely already being exploited.
When we found the list of the people on the team we weren’t all that surprised that there were problems with the security reviews based on the makeup of the team. What was the most striking thing was that there are only six people on the Plugin Directory team. That is six people managing a directory of over 52,000 plugins. That obviously isn’t enough and it isn’t surprising things are not being properly handled.
It isn’t like the lack of proper handling is new though, looking back at our archives it was back in early 2012 (which was well before we started this service) that we started trying to get the Plugin Directory team to simply visit a page on a security company’s website where the company listed confirmed vulnerabilities in WordPress plugins. Through that the Plugin Directory team could have easily seen many plugins that had known vulnerabilities in the current version and they could have taken additional action. Instead, for a while the only reason anything got done about those plugins was because we would email them the relevant plugins. When we didn’t have time to do that, vulnerable plugins would remain in the Plugin Directory.
Another thing we noticed about the makeup of the team is that third of the members work for directly for WordPress founder Matt Mullenweg. By work for him we don’t mean they work for the company closely tied to WordPress, Automattic, but for Audrey HC, LLC, which has six people including Matt. That is a problem because either Matt doesn’t understand the security landscape around WordPress or he is part of covering up the reality of the poor state of things. Either one of those options could be in line with what we have seen with one of his employees, so possibly that person is misleading him or they are acting in concert with him.
Back in February he wrote on a post on medium.com where he listed what he claimed were the “biggest issues to WordPress security”:
What are the biggest issues to WordPress security?
A good order of priority based on impact would be:
- Sites not updating core.
- Sites not updating plugins.
- Sites not updating themes.
- Weak passwords, without brute-force protection or two-factor authentication.
- Hosts (professional or ad-hoc) not scanning and fixing sites.
- Hypothetical issues not seen in practice, which distract from the above existing priorities.
It would be great if the only non-hypothetical issue when it comes to plugins was them not being updated and it certainly would make our service of little use, but unfortunately that isn’t true. We could point to the recent prominent issue of plugins being purchased and then being made intentionally malicious, but that occurred after that list was made.
One issue that isn’t new is the issue of zero-day vulnerabilities, which are vulnerabilities that are being exploited before the developer becomes aware of them. As an example take the plugin Asgaros Forum, which back in the middle of August had a vulnerability that hackers were exploiting. After the developer became aware of that they quickly figured out what was going on and fixed it. We had concurrently found the problem as well, notified them of that as they were fixing it, and helped to make sure a much more limited version of the vulnerability that wasn’t fixed in the original fix then got fixed.
Keeping your plugins up to date wouldn’t have prevented that from being exploited at first, but it did get quickly fixed once it was being exploited at a wider scale. That isn’t always the case. Take the plugin Delete All Comments, which was discovered by NinTechNet, makes of the plugin NinjaFirewall, to have a vulnerability when they were cleaning up a website that had been hacked through the vulnerability. Delete All Comments had 30,000+ active installations at the time. NinTechNet notified the developer of the plugin and got no response. (There was the thought by some that this wasn’t so much a vulnerability but intentionally malicious code, which was based in part on the code being introduced in the first version released by a new developer and might explain it not being fixed.) The Plugin Directory was notified and the plugin was removed.
NinTechNet then disclosed the vulnerability on December 10th and several days later we started see what look to be wide scale to exploit the vulnerability. We recently had some requests on our website that looked to be someone checking to see if the plugin was on our website, so the attempts to exploit it are likely still ongoing. It easy to see why, since the plugin never was fixed, as you can see that were it would be in the Plugin Directory, it isn’t, and the most recent change made was on September 6, 2016, which was before the vulnerability was discovered by NinTechNet. So keeping your plugins up to date would have not provided any protection. In testing we did at the time we found that none of the 15 security plugin we tested prevented exploitation of the vulnerability either (the free data that comes with companion plugin for our service would have warned you about it though).
Matt would seem to either believe that is hypothetical or wants you to believe that, but that issue is very real.
In July of last year, one of Matt Mullenweg’s employees who is part of the Plugin Directory team gave the following response in regards to another plugin that had been pulled from the directory after it was being exploited (which also never was fixed):
If we pull the plugin for security reasons, then the author usually patches it. If it’s severe enough, we may patch it ourselves after an author does not respond. This is handled on a case by case basis.
We responded to that with the following:
Seeing as we are the people that are reporting many of the vulnerabilities to the Plugin Directory that cause plugins to be pulled, we can say that the reality is that plenty of those plugins never get fixed. In other cases they are not fixed in a timely manner. Also, in some cases you guys put the plugin back in the Plugin Directory even though the vulnerabilities have not actually been fixed, including a recent case where it looks like a hacker had been exploiting a plugin prior to it being removed from the Plugin Directory.
In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this. Not only does the plugin have an easily exploitable vulnerability, but it appears that a hacker is already exploiting it. That is how we became aware of the issue in the first place.
We never got a response from them to that and not to long after that our response was deleted. At best you have someone that is ignoring the reality of the situation and at worst you have an ongoing cover up of what is going. Matt Mullenweg would appear to be part of one of those.
There is now another problem with all of this, currently by what is in our data there are plugins with about 1.3 million active installations that have publicly disclosed vulnerabilities that remain in the Plugin Directory. Many of those vulnerabilities are not likely to be exploited on the average website, but a few our. Keeping your plugins up to date obviously doesn’t address that. What would address that is concrete plans to fix a couple of the problem with WordPress handling of security, ones that Matt Mullenweg and everyone else on the WordPress side of things have shown no interest to do so far. Once those are in place we would go back to doing the work the Plugin Directory has failed to do for years and that no one else has done either (having a larger Plugin Directory team could also help to get that situation resolved). One the problems that needs a concrete plan to fix is that currently when plugins are removed from the Plugin Directory, WordPress doesn’t notify those using the removed about that, which making happen would obviously help to provide more protection against unfixed vulnerabilities.
The problems with Matt Mullenweg’s involvement extends beyond on this, as we will get to when we discuss the employer of another member of the Plugin Directory team (who is also being paid for the WordPress work they do) in another post.
Due to the year’s long problem we think that at this time not only does WordPress need new leadership, but a better governance structure that is better aligned with the size and importance of WordPress, because clearly what is in place now is leaving a lot to be desired.