In monitoring the WordPress Support Forum for indications of vulnerabilities in plugins so that we can warn our customers of any publicly known security issues in plugins they use we have been seeing for sometime complaints about about problems with bogus signups on subscriber lists for newsletter plugins. It isn’t clear what the point of that would be or it is even intentional (if some knows what the explanation for that is please leave a comment). One of those plugins being, Email Subscribers & Newsletters, where someone began a topic seven weeks ago with this:
In our previous post we mentioned how Wordfence was lying about us related to a vulnerability in the plugin Related Posts (Yuzo Related Posts), but they also got something else wrong that is worth noting. One section of their post titled “is_admin() Strikes Again”. In that they write this:
This Vulnerability Details posts provides the details of a vulnerability we ran across while collecting data on vulnerabliities discovered by others for our data set on vulnerabilities in WordPress plugins, so its contents are limited to customers of our service.If you are not currently a customer, you can sign up for free here. There are a lot of other reason that you will want to sign up beyond access to posts like this one, including that you would have already been warned about this vulnerability if your website was vulnerable due to it.
When it comes to the security of WordPress plugins what other security companies generally do is to add protection against vulnerabilities after they have already been widely exploited, which obviously won’t produce great results since there is a good chance the websites using their service have already been hacked by the time they do that. One of the ways we keep ahead of that is to monitor the closure of the 1,000 most popular WordPress plugins in the Plugin Directory, since that closure can be due to a security issue and even if it is not, we have found the plugins being closed often contain security vulnerabilities, and as was the case with one less than two weeks ago, ones likely to be exploited. Hackers seem to be doing that type of monitoring as well. Through that we found that the plugin Visual CSS Style Editor, which has 30,000+ active installs and was closed yesterday, has two vulnerabilities that when combined lead to a type of vulnerability hackers would be likely to exploit.
Occasionally our proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities catches an easy to confirm vulnerability and that was the case with an authenticated remote code execution (RCE) vulnerability being introduced in to the plugin Groundhogg, which is also exploitable through cross-site request forgery (CSRF).
While we already are far ahead of other companies in keeping up with vulnerabilities in WordPress plugins (amazingly that isn’t an exaggeration), in looking in to how we could get even better we noticed that in a recent instance were a vulnerability was exploited in a plugin, we probably could have warned our customers about the vulnerability even sooner if we had looked at the plugin when it was first closed on the Plugin Directory instead of when the vulnerability was fixed (though as far as we are aware the exploitation started after we had warned our customers of the fix). So we are now monitoring to see if any of the 1,000 most popular plugins are closed on the Plugin Directory and then seeing if it looks like that was due to a vulnerability.
In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.
When it comes to security of WordPress plugins, what other security companies generally do is to add protection against vulnerabilities after they have already been widely exploited, which it should be pretty obvious doesn’t produce good results. By comparison, we do proactive monitoring of changes made to plugins in the Plugin Directory to try to catch serious vulnerabilities, but we only have so much time to do that with the amount of customers we have, so we have a backlog of possible vulnerabilities that didn’t look like serious issues that we haven’t had time to get to. Sometimes, as is the case, with the plugin SupportCandy when the plugin comes up again with that proactive monitoring we realize that vulnerability was more serious, as the plugin contains an arbitrary file upload vulnerability, which is the kind that hackers are likely to exploit.