You’ve Found a Vulnerability! Now What? A Guide to Responsible Disclosure.
Information security researchers make a valuable contribution to our online security by finding vulnerabilities and facilitating getting them fixed. Wordfence has been finding and disclosing vulnerabilities in WordPress core, WordPress plugins, and WordPress themes since 2011. Our research has exposed vulnerabilities in the core infrastructure that powers WordPress, organized crime exploiting plugins for profit, and our research has extended to major external vendors.
The research and engineering team at Wordfence are highly credentialed cybersecurity professionals who have developed a reputation for groundbreaking research, and professionalism in working with vendors to get vulnerabilities fixed. Wordfence recently became a Certified Numbering Authority, which empowers us to work with researchers in the WordPress security space and assign CVE identifiers to their research to help track the vulnerabilities they identify.
Today we are publishing this guide to responsible disclosure. This is designed to help new researchers understand the process of working with vendors to get vulnerabilities responsibly disclosed, fixed by the vendor, and released to the general public. If you are a researcher, understanding this process is essential if you are to perform security research in a safe and sustainable way. Not using responsible disclosure is seen as irresponsible behavior in the information security community, and can quickly end what might have been a promising career in cybersecurity.
This guide also helps you understand when you should apply to us for a CVE for your vulnerability and how to do that.
Using responsible disclosure to fix vulnerabilities is tremendously rewarding. It provides researchers with the opportunity to protect the general public from exploitation, while also getting the credit they deserve through safely publishing their research. Responsible disclosure is the backbone of safe and effective cybersecurity research.
Outlining the Responsible Disclosure Process
After every vulnerability discovery, it is important to disclose the findings to the vendor or developer of the product so that they can create a patch to remediate the vulnerability. This helps to ensure that users are safe from any malicious threat actors looking to exploit unpatched vulnerabilities.
Responsible disclosure is the process of safely reporting these details to the appropriate party so a patch can be released without granting malicious threat actors the information needed to exploit the vulnerability in the interim period it takes from discovery to the release of a patch.
The sequence of vulnerability discovery to responsible disclosure is as follows:
- Perform the research necessary to find a vulnerability.
- Find a vulnerability and verify that it has not previously been disclosed.
- Initiate the disclosure by contacting the vendor responsible for maintaining the product or service in question.
- Provide the vendor with the full information they need to implement a fix along with an expected timeline.
- Confirm that the vendor has fixed the vulnerability and released it to their customers.
- Apply to Wordfence for a CVE ID assignment to help uniquely identify the vulnerability that you found. Our team moves quickly on this and you should receive your CVE promptly.
- Publish your research, along with your CVE to uniquely identify your vulnerability.
Initiating the Disclosure – Making Initial Contact
When first reaching out to a vendor, it is important to determine who to contact to report a security issue, and how to contact them. We always recommend looking for a responsible disclosure policy for the affected software first. Ninja Forms is a great example of an organization that has a security policy with clear guidance on how to report a security issue found in their products. If an organization has a responsible disclosure policy then we recommend following the policy the organization has outlined to report any security issues.
Unfortunately, we frequently find that many organizations do not have public security disclosure policies in place. More commonly, you will have to find a contact. Most plugin or theme developers will have a site with a contact form, email address, or support forum available to initiate contact with them. However, in some rare cases, you may need to get creative and look in the plugin or themes readme.txt file to find contact information or look for any social media accounts you can reach out to.
In these cases, where there is no clear guidance on how to report security issues to the vendor, we recommend making an initial outreach via whichever contact method you were able to find, and ensure this initial outreach contains no vulnerability information. This initial outreach should just confirm the appropriate channel to handle the discussion and ask for an alternative contact method if one is required for the disclosure.
The following is a template that can be used when attempting to make initial contact with a developer or vendor:
|
Hi there! My name is [name here]. I am a WordPress security researcher. I’m reaching out regarding a security issue we’ve identified in your product [product name]. Please confirm if this is an appropriate inbox for handling this discussion, or provide an alternative contact for us to reach someone on your team responsible for product security. We’ll provide the issue’s specific details at that time. If we do not receive an initial response from you in 7 days we will be escalating this to the appropriate party. [Optional: Additionally, please refer to our vulnerability disclosure policy, located at [security policy location]. This document outlines the typical steps and timeframes associated with this process.] I appreciate your prompt response, |
Special Note for WordPress Core and Automattic Products
If you find a vulnerability in WordPress core or in an Automattic product like WooCommerce, Jetpack, or WP Job Manager, just to name a few, then you may be eligible for a bounty. WordPress and Automattic have bug bounty programs on HackerOne that make it easy to responsibly disclose vulnerabilities in their products and receive payment for any discoveries within their specified scopes. As such, we highly recommend using the HackerOne platform to report any WordPress core vulnerability discoveries or any Automattic product vulnerability discoveries. You can find the Automattic HackerOne Program here and the WordPress.org HackerOne program here.
What Should Be Included In a Vulnerability Report?
There are many things that should be included in a vulnerability disclosure report. The three most critical things that should be included are: a proof of concept that explains or demonstrates how the vulnerability can be exploited, a description of the vulnerability that discusses what components are affected along with what type of vulnerability is present, and a recommended remediation for the vulnerability that can guide the developer to an optimal patch for the vulnerability.
In addition to those three things, we recommend including a link to, or snippet, of the code that is affected, a CVSS score and vector, an exploit title, and the version of WordPress that the vulnerability was tested on. Any information that can be used to assist the developer in patching the vulnerability should be included.
The following is a template that can be used when disclosing the details of a vulnerability to a developer or vendor:
|
Hello {CONTACT/ORG}, Thank you for confirming the inbox for handling this disclosure. The vulnerability’s details are outlined below. Exploit Title: [Product Name Affected] – [Type of Vulnerability] Description Proof of Concept Affected Code Recommended Solution You should be aware that other researchers may independently discover this vulnerability and announce it prematurely. You should also note that this vulnerability may be exploited in the wild already. For these reasons, we encourage you to release a fix as soon as possible to help protect your customers. As a courtesy we ask that you notify us as soon as you release a fix to your customers. Please let me know if you have any questions. Thank you, |
Reasonable Time Frames for Response and Remediation
We recommend providing developers and vendors at least 7 days from an initial contact attempt to confirm the inbox for handling the disclosure. There may be cases where a developer or vendor is on vacation or busy performing other tasks, so it is important to give them enough time to respond to your initial inquiry.
If you do not hear back from the developer or vendor within 7 days of your initial outreach, and you have exhausted all resources to make contact with them, we recommend escalating the issue to the appropriate party. Please see “What to do when you receive no response in a given timeframe?” below.
After The Vulnerability Has Been Disclosed to the Vendor or Developer
If you have made contact with the developer or vendor and successfully disclosed the vulnerability’s details then we recommend working with them for as long as reasonably possible to get the vulnerability remediated. In most cases, this will take no longer than a week. However, in some rare cases, it could take weeks or months of working with a developer for a vulnerability, or vulnerabilities, to be remediated. In those cases, it is best to provide as much guidance as possible and follow up with the developer or vendor as needed to ensure a patch gets released.
If at any point the developer stops responding or appears to be making no effort to remediate the vulnerability, then we recommend escalating the issue to the appropriate party. Please see “What to do when you receive no response in a given timeframe?” below.
What to do when you receive no response in a given timeframe?
If no response is received from a vendor or developer within the given time frame, then it is time to take the next step and escalate the situation to the appropriate party.
In cases where the vulnerability is in a product that is hosted on the WordPress.org plugin or theme repository, we recommend escalating the situation to the WordPress plugins team. The WordPress handbook has a guide to reporting security issues to the plugins team that can be found here. This should always be a method of last resort as the plugin’s team may need to close the plugin for downloads if the developer or vendor becomes completely unresponsive.
In cases where the vulnerability is discovered in a product outside of the WordPress repository, we recommend escalating the issue to the vendor or marketplace that is hosting the sales or downloads of the product. For example, there are many premium plugins and themes available on the Envato Marketplace and there have been cases where developers have been unresponsive to contact attempts. Fortunately, Envato Marketplace is also a great example of a marketplace that provides clear guidance on how to report these issues and they will take the appropriate action in the event of an unresponsive vendor.
In cases where a vulnerability is discovered in a product that is hosted somewhere with no higher authority, the best course of action may be to publicly disclose the vulnerability while providing minimal details. This is to bring awareness to site owners so they can remove the plugin or theme from their site while ensuring the disclosure does not provide enough information to enable any malicious threat actors. This should always be a method of last resort.
When to apply to Wordfence for your CVE?
Once the vendor has released a patch to their customers and you are ready to publish your research, you should apply to Wordfence for a CVE to uniquely identify your vulnerability, using the form you’ll find on this page. Our team will promptly issue your CVE, provided we receive the required information, and you should include this identifier in your public disclosure.
Including a CVE in your public vulnerability disclosure will help other vendors recognize and disambiguate your vulnerability from others.
When should the vulnerability be made public?
Vulnerability discoveries should only be made public after the vulnerability has been patched, or after the vendor has been unresponsive for long enough, and you have escalated the situation as required. If at all possible, a remediation action, like updating or removing a plugin, should be available for users before the vulnerability’s details are divulged so that they have a way to protect their WordPress site.
Vendors may request that you wait a certain amount of time prior to publicly disclosing the vulnerabilities details; it is best to honor those requests. However, if no timeframe is given, we recommend waiting at least 7 days after a patch prior to publicly disclosing vulnerabilities, to provide users time to update before a vulnerability becomes publicly known. This timeframe can differ depending on the severity of the vulnerability and likelihood of exploitation.
Please note that in cases where a vulnerability is being actively exploited before a patch is available, that vulnerability is considered a 0-day, and users should be alerted as soon as possible, though minimal details should be released before a patch is made available. This is to ensure that site owners can protect their sites by removing the theme or plugin while waiting for a patch to be released.
We’re here to help!
Wordfence has been performing successful vulnerability research and responsible disclosure for over a decade. As a CNA, we are available to support you in your research efforts. You’re welcome to contact us for advice on how to get a vulnerability fixed and responsibly disclosed.
To contact us with questions, email cve-request@wordfence.com. This will open a ticket for our researchers and they will assist you as needed.
Conclusion
In today’s post, we outlined the best approach to take when it comes to responsibly disclosing vulnerabilities in WordPress plugins, themes, and core. Responsible disclosure is a collaborative effort that incentivizes researchers to perform the valuable security research that keeps the online community safe, while ensuring that vendors are confidentially alerted to flaws in their products, that they can fix, and ensure that their own user community stays safe.
We hope that this will serve as a guide to the many WordPress security researchers who are actively discovering vulnerabilities and are not sure what the next steps to take are. Remember, you are doing good work helping to secure the online community, and we are here to help and to support you in your efforts. Good hunting!
Comments