New Service Vulnerability Disclosure Policy
New Service Vulnerability Disclosure Policy
The Wordfence team regularly discovers security issues with commercial services, such as WordPress hosting providers, that put their users at risk. In some cases, the issue is quite severe, putting thousands of websites at risk simultaneously. In these instances, our standard approach has been to contact the service provider directly, provide them with the details and work with them toward resolution. Lately these issues have become more common, so we’ve decided to formalize our approach going forward, updating our Vulnerability Disclosure Policy to specifically address these scenarios.
What Is a Service Vulnerability?
We define a service vulnerability as any issue with a technology service that represents an exploitable security risk for its users. We draw a distinction between service and software vulnerabilities, because in many cases, the service vulnerability is due to configuration issues instead of a software bug. For example, a WordPress host may set file permissions incorrectly, allowing an attacker to easily move laterally between sites in their environment. The hosting company may be running no vulnerable software while still opening their customers up to attack.
How Does Wordfence Discover Service Vulnerabilities?
Our Security Services Team cleans hundreds of hacked websites each month. As part of that service, they analyze the available server logs, configuration and other server information to try to identify how the website was compromised. This is really important, as it is the only way to be certain that they’ve closed the security hole the attackers used to hack the website in the first place. It is during this analysis that we occasionally discover security issues with hosting providers. In most cases, we will see a flood of site-cleaning cases immediately following the first discovery, all from the same host.
Wordfence Service Vulnerability Disclosure Policy
When the Wordfence Security Services Team discovers a security vulnerability in a service, such as WordPress hosting, we take the following steps to address the issue:
- Our research team verifies the vulnerability.
- We notify the service provider, using the following disclosure deadline, based on the day the service provider is notified:
- 90 days
- 14 days if the vulnerability is being actively exploited
- Where this service vulnerability directly affects a customer, we will notify that customer that they should consider changing hosting providers. We will not provide technical details of the service vulnerability until we disclose publicly. Instead, we use the following language: “We recommend at this time that you change hosting providers to resolve this security issue. We can not provide further details at this time, but have contacted the hosting provider directly about this issue.”
- The service provider releases a fix or the deadline passes, and we announce the vulnerability via our blog.
Why We Impose Disclosure Deadlines
When determining our approach to disclosure deadlines, we had to balance the needs of customers, service providers and the broader WordPress community. Let’s take a look at the perspectives we needed to balance:
As a customer of a service provider with a service vulnerability, I would want to know about the issue right away so I could take action. I also wouldn’t want additional attackers to be notified, increasing the odds that my site might be compromised, but if the vulnerability is being actively exploited, I would expect those involved to “drop everything and fix it!” I would be able to tolerate you keeping it confidential for a short time to allow the service provider reasonable time to implement a fix, but not for very long. As a paying customer, I would feel I deserved to know so I could take action to defend myself.
Service Provider Perspective
As a service provider with an issue, I would want a reasonable time to develop, test and deploy a fix. Many service providers have massive customer bases and complex infrastructure challenges. I may also have other high priority issues that I’m in the middle of handling, forcing me to make difficult choices.
WordPress Community Perspective
The broader WordPress community needs to know that, in general, when service providers discover security issues, they are dealt with quickly. We all need service providers we can trust, and we rely upon each other to keep the WordPress ecosystem safe and hold service providers accountable.
A Balanced Approach
We had an animated discussion about how aggressive the deadline should be for service providers. Where we landed is quite simple: if a vulnerability is being actively exploited, we expect the service provider to literally drop everything and fix the problem. If they do that, our deadline of 14 days should be plenty of time to implement a fix that they’ve properly tested and doesn’t break other things. If the vulnerability isn’t being actively exploited, 90 days is still reasonable for even the largest providers in our industry.
As always, we reserve the right to change deadlines based on discussions with the provider. Our interests are aligned with those of the community, and we will always do what we feel is the right thing.
Software Vulnerability Disclosure Deadline Change
As a result of this conversation, we also reviewed our policy for software vulnerabilities, and have decided to make a change to how we handle disclosure deadlines. In the past, we have always given the author a 30-day deadline to publish a fix. In the large majority of cases, the author posts a fix within a day or two. Unfortunately, some authors are not so responsive. Going forward, in cases where a software security vulnerability is being active exploited, our disclosure deadline will now be seven days. We feel this is very reasonable, as fixing a security vulnerability in a piece of software like a WordPress plugin or theme is much easier than rolling out a configuration change to thousands of mission-critical production servers.
We take our role as the leading security vendor in the WordPress ecosystem seriously. We feel that these updates to our approach will benefit service providers, software authors, their customers and the broader WordPress community. We encourage other security researchers to adopt similar policies and invite you to reach out to us with any questions you have about implementing a similar approach.