On Friday we noted that the moderators of the WordPress Support Forum were getting in the way of people trying to discuss dealing with being hacked due to a vulnerability that had been in the plugin WP Live Chat Support. Looking again yesterday showed that has continued. Here is one topic that was closed without explanation why that even happened. With another one, it was closed due to someone mentioning they were using a pro version of the plugin, that is even though the issue the person was bringing up was caused by the vulnerability being exploited, which has nothing to do with a pro version. Someone could have pointed that out to the moderator that closed it, if they hadn’t closed the topic (not surprisingly the problematic moderator there was once again Jan Dembowski).

Looking at the reviews of the plugin we noticed one from over the weekend titled “Lost a ton of business. Infected with malware.“:

If you have a woocommerce site and depend on sales, stay far away from this plugin.
Malware was injected with the plugin.The code is terrible and still has holes in it after they fixed it. This is the first time we have had a hacked site. After we deleted the plugin, the hack was gone but our Google Adwords got suspended. The review team can’t fix it until Monday. We lost 60k in sales this weekend. Going back to ZenDesk chat and will remember this plugin developer for a longtime.

That is a pretty common type of complaint after vulnerabilities in WordPress plugins are widely exploited. Also as is common, this situation could have been avoided. In this case having plugins automatically update would have gotten them to a version that wasn’t vulnerable to be being exploited before exploitation looks to have started. That is really the best option to avoid a lot of exploitable vulnerabilities, but our service could have also warned them about the vulnerability before it was exploited as we warned our customers if they were using a vulnerable version of the plugin shortly after it was fixed and disclosed, which was a day before it looks like it started getting exploited.

The claim made in that that there are still holes in the plugin seems like it could be based on comments we had made. We did some further checking while adding the exploited vulnerability to our data set, after that we disclosed one vulnerability and mentioned there were more. That gets to the best approach to the security of plugins being used on a website that is critical to a business, like it sounds was the case for that reviewer, which is to have a thorough security review done of plugins used.  As security issues with this plugin would have not been hard to spot if one of those had been done. At least with the security reviews of plugin we do, the exploited vulnerability would have been almost impossible to miss since it would have been specifically something that three of the checks we do would have been looking for:

• Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
• Security issues with functions accessible through the admin_init action
• Security issues with usage of add_option(), delete_option(), and update_option()

With the latter two of those checks, we specifically include checking for those due to those being something we have seen being implicated in previous widely exploited vulnerabilities.

Yet another one of the checks would have spotted this, even though it is intended to sport a different type of vulnerability:

• Reflected cross-site scripting (XSS) vulnerabilities

More plugins getting those types of security review could be big help to the whole WordPress community since everyone using the plugins would benefit from either any vulnerabilities that are found being fixed or being able to be aware that the developer is neglecting the security of the plugin.