One of the issues we continue try to find the best way to handle is the disclosure of vulnerabilities we discover. On the one hand the people that are paying for our service (and therefore ultimately have made those discoveries possible) deserve to get notified in a timely manner when they are using a WordPress plugins with a known vulnerability. On the other hand if the vulnerability hasn’t been fixed yet, disclosing it increases the chances of it being exploited. While our customers will be aware of the vulnerability and we can help to them to mitigate their risk, everybody else using the plugin else remains vulnerable.

To try to balance those two things we attempt to notify the developer of the plugins and give them a chance to fix it before disclosing the vulnerability. How long to wait is one of the items we continue to look at and often isn’t one that fit neatly with standard disclosure periods. For example, if a vulnerability is already likely being exploited, as many we have found are, then waiting 30 or 90 days for a fix would mean that lots of website could be hacked in the meantime, which is far from ideal. Currently for those type of vulnerabilities we usually wait a few days at most for a fix before disclosing the vulnerability. To make sure as many people as possible are warned right away we publicly disclose it at the same time that we start warning our customers, so that other providers have a chance to warn their customers, and we also add the vulnerability to the free data that comes with our service’s companion plugin, so that anyone that has it installed will also start getting notified even if they are not using the service yet.

Disclosing vulnerabilities also sometimes leads to unpleasant interactions with the developers of software that seem more interested in hiding that a vulnerability has existed then actually fixing it. Today ZDNet had a story about PwC (formerly PricewaterhouseCoopers) responding to notification of a security vulnerability in their software with the threat of legal action:

A portion of the cease-and-desist letter, seen by ZDNet, said that PwC demanded the researchers “not release a security advisory or similar information” relating to the buggy software. The legal threat also said that the researchers are not to “make any public statements or statements to users” of the software.

Not only does this do nothing to fix this particular vulnerability, which someone else with malicious intent could find (or already has found) and start exploiting, but each time a company does this it makes it less likely that other vulnerabilities in software are going to be reported to the developers in the future, making everyone less secure.

In our dealing with developers we have yet to get any legal threats, but we have on occasion we have gotten responses that we don’t find all that appropriate. One of those occurred today.

Back in September we discovered an authenticated cross-site scripting (XSS) vulnerability in the plugin wpDataTables Lite, in part based on a disclosure of a previous vulnerability in a paid version of the plugin. The developer responded later the same day that they would be including a fix for it in the next release, since it was a type of vulnerability that isn’t likely to be exploited we didn’t have a problem waiting for that to be released. In hindsight that seems to have not been a great idea as the next version wasn’t released for three months (we are currently looking at having a policy to have a limit on how long we wait in this type of situation). So at least after three months it had been fixed right? No.

After finding that there wasn’t’ anything that looked like an attempt to fix the vulnerability in the new version, yesterday we disclosed the vulnerability and reported the issue to the Plugin Directory. Once a vulnerability has been reported to the Plugin Directory, unless it is very minor, the relevant plugin will be removed pending a fix. Our experience is that often will quickly lead to a vulnerability being fixed that has been ignored by the developer, but it also can lead to it taking longer for a fixed versions to get to users of the plugin, as it can take a while for the Plugin Directory restore the plugin after a fixed version has been submitted.

This morning we got an email from the developer asking us to remove the post. After explaining how they had failed to include the fix in the new version, they made the following remarks which in part questioning our motives:

Of course that’s our fault, and our mistake that we didn’t resolve that quicker, however we truly hope that your primary goal is to keep WP sites secure, not to have as many of them hacked as possible, through a published exploits DB. We hope hacker’s sites did not yet notice the article to re-publish it and distribute an exploit – and I hope you don’t want this to happen.

Probably the most important is that this type of vulnerability is very unlikely to be exploited on your average website, so the risk of disclosing it is minimal. Where it might be used is in a targeted attack, of which there are not many of, and in which it should be easy for someone doing that to find the same vulnerability.

After we responded explaining why disclosing vulnerabilities is important (we have help to get numerous vulnerabilities fixed due to disclosures made by others) and the fact that if not for people disclosing vulnerabilities our services wouldn’t exist and therefore the vulnerability in their plugin would likely remained there for the foreseeable future, we got more responses questioning are interest in making WordPress more secure.

It is frustrating when developers that haven’t secured their own code are questioning the interest of those trying to actually doing the work to limit the damage that has, instead of promptly resolving their own problem.