WordPress Team Helping to Introduce Remote Code Execution (RCE) Vulnerability on to Thousands of Websites
When do a lot to improve the security of WordPress websites through the work we do on the security of WordPress plugins for our service (in all likelihood we do more than all the other security companies with a WordPress focus combined). Unfortunately what we have found is that people on the WordPress side of things seem more interested in covering up problems related to the security of plugins (and promoting security companies that are making WordPress websites less secure) than actually working with others, like us, to improve them.
In response to part of that problematic behavior, we started full disclosing vulnerabilities in WordPress plugins until such time that the moderators on the WordPress Support Forum stopped acting inappropriately. Through that on January 11 we full disclosed a remote code execution (RCE) vulnerability that has been introduced in to the plugin MailPress, which was closed on the Plugin Directory at the time. We spotted that vulnerability through our proactive monitoring of changes being made to WordPress plugins to try to catch serious vulnerabilities when they are introduced in to plugins. As part of our full disclosure process we tried to notify the developer of the issue through the WordPress Support Forum, but that message got deleted by the moderators. You might think that while deleting that they would at least make sure that something was done about the vulnerability, but as we already said, they and others on the WordPress side of things are more interested in covering up problems than fixing them.
Then last week the plugin was reopened on the Plugin Directory with the RCE vulnerability still there. The plugin has 3,000+ active installations according to wordpress.org and those websites are now being prompted to update to a new version that will introduce that vulnerability on to their website.
That shouldn’t have happened, not just because the WordPress team was aware of the issue through our message on the Support Forum about the vulnerability, but because the vulnerability is also able to be picked up by our Plugin Security Checker, an automated tool for identifying some possible security issues in plugins. What we have noted in the past is that the team running the Plugin Directory is failing to catch serious vulnerabilities during their supposed manual security review of new plugins and we have offered them to provide the free access to the more advanced mode of our Plugin Security Checker, to avoid that. If they had taken advantage of that and checked the plugin before it was reopened (it looks like it had been closed due to another security issue) they would have been warned about the possibility of the vulnerability:
Until such time that the Matt Mullenweg or someone else at the top of WordPress is able to act like an adult and clean up the mess that is the WordPress team (much of the problem is caused by Samuel “Otto” Wood, who is a direct employee of Matt’s), these problems are likely to continue. In the meantime our service can help to ameliorate the damage, as if you were using service and this plugin you would be have been warned about this vulnerability already, so you wouldn’t be unaware of the security risk that WordPress is okay with introducing on to your website.