Vulnerability Disclosure Policy

Last updated: 12/15/2016

We believe in reasonable disclosure, which involves providing developers notification of vulnerabilities we will disclose ahead of the disclosure, but doesn’t involve waiting potentially forever for a developer to fix the vulnerability.

Many of the vulnerabilities we disclose are likely already being exploited, so not disclosing them means that people using the plugin are left completely vulnerable, whereas with disclosure they have a chance to do something. Therefore we will quickly disclose those. For those vulnerabilities we include the data on them in the free data that comes with our service’s companion plugin, so even those not using the service yet can be notified of the issue. Other providers also have the ability to include the vulnerabilities in their data, since we disclose them publicly at the same time.

For some other vulnerabilities we disclose, the vulnerabilities are rather obvious when looking at a report of another vulnerability in a plugin. If we have spotted those you can be sure that others could as well, so keeping quiet about them doesn’t do much to limit the possible of their exploitation and we will usually quickly disclose those.

As the funding for our discovering all of these vulnerabilities comes from our customers paying to be notified of vulnerabilities in the plugin they use, keeping quiet about them for a significant amount of time is also shortchanging our customers.

For vulnerabilities that are not being exploited or are not obvious due to previous vulnerability we will disclose them 30 days after notifying the developer if the developer responds to our notification or 7 days if they don’t respond, or after they have been fixed, whichever comes first. For vulnerabilities where the developer is no longer around (which is fairly often with WordPress plugins), we will disclose them immediately.

For all vulnerabilities that have not been fixed when disclosed, we notify the Plugin Directory at the same time.