Vulnerability Disclosure Policy

As a provider of security software, services, and research, we take security issues very seriously and recognize the importance of privacy, security, and community outreach. As such, we are committed to addressing and reporting security issues through a coordinated and constructive approach designed to drive the greatest protection for technology users. Whether you’re a user of Rapid7 solutions, a software developer, or simply a security enthusiast, you’re an important part of this process.

Reporting security issues

If you believe you have discovered a vulnerability in a Rapid7 product or have a security incident to report, please fill out this contact form. If you feel the need, please use our PGP public key - KeyID: 959D3EDA - to encrypt your communications with us.

Once we have received a vulnerability report, Rapid7 takes a series of steps to address the issue:

  1. Rapid7 requests the reporter keep any communication regarding the vulnerability confidential.
  2. Rapid7 investigates and verifies the vulnerability.
  3. Rapid7 addresses the vulnerability and releases an update or patch to the software. If for some reason this cannot be done quickly or at all, Rapid7 will provide information on recommended mitigations.
  4. Rapid7 publicly announces the vulnerability in the release notes of the update. Rapid7 may also issue additional public announcements, for example via social media, our blog, and media.
  5. Release notes (and blog posts when issued) include a reference to the person/people who reported the vulnerability, unless the reporter(s) would prefer to stay anonymous.

Rapid7 will endeavor to keep the reporter apprised of every step in this process as it occurs.

We greatly appreciate the efforts of security researchers and discoverers who share information on security issues with us, giving us a chance to improve our products and services, and better protect our customers. Thank you for working with us through the above process.

Coordination is key

When properly notified of legitimate issues, we’ll do our best to acknowledge your emailed report, assign resources to investigate the issue, and fix potential problems as quickly as possible. When we discover vulnerabilities through our own research, we will do our best to coordinate efforts with the vendor's security teams and CERT/CC.

Rapid7’s Vulnerability Research and Disclosure Principles

    1. We believe in strengthening defense by democratizing access to attacker tooling and knowledge. One of Rapid7’s unique strengths is our deep knowledge of how attackers work. Our vulnerability research and Metasploit teams strive to make attacker capabilities that would otherwise be used primarily by criminals accessible to all — enabling defenders to understand and prioritize critical vulnerabilities, develop detections and mitigations, and test security controls. Releasing public exploit code and novel research is core to our mission to close the security achievement gap.
    2. Public disclosure of vulnerabilities is a critical component of a healthy cybersecurity ecosystem. Rapid7 practices and advocates for timely public disclosure of vulnerabilities across both third-party products and our own systems and solutions. This includes vulnerabilities we independently discover in our customers’ tech stacks. Through transparent, open, and timely vulnerability disclosures, Rapid7 helps the entire internet protect and defend those assets and services critical to modern civilization.
    3. In today’s threat landscape, organizations need timely information about risk in order to make educated choices about protecting their networks — especially during active attacks. Our vulnerability disclosure policy includes explicit provisions for speeding up public disclosure in cases where exploitation has been observed in the wild. Vendors often (understandably) act to protect their own businesses and reputations when there are security issues in their products that introduce risk into their downstream customers’ environments. When we know about exploitation in the wild, or when we believe that threat actors may be covertly weaponizing non-public vulnerabilities, our priority is to make customers and the community aware of that risk so they may take action to protect their organizations.

Coordinated Vulnerability Disclosure (CVD) Policy

In keeping with standard industry practices around Coordinated Vulnerability Disclosure (CVD) (such as CERT/CC's, Google's, ZDI's), as well as the standards promulgated in ISO 29147 and ISO 30111, Rapid7 will typically prepare and publish advisories detailing newly discovered vulnerabilities approximately 60 days after our initial attempts at private disclosure, barring extenuating circumstances (including those outlined below which may warrant different disclosure guidelines). These advisories will be made publicly available via Rapid7’s blog and social media. Depending on the details of the findings, there may also be media engagement.

While coordinated vulnerability disclosure can differ from bug to bug depending on a wide range of circumstances, Rapid7's primary concern is getting vulnerabilities fixed and making affected parties aware of the risks associated with vulnerabilities. In keeping with the principles outlined above, Rapid7 has identified several common types of vulnerabilities, each of which warrants slightly different disclosure guidelines.

Please note, technical vulnerabilities often involve undefined behavior and unexpected interactions. Therefore, Rapid7 may modify the timeline for disclosure at our sole discretion due to unique or unpredictable elements of that specific vulnerability.

All Vulnerabilities (The Default Policy)

    1. Rapid7 will confidentially disclose discovered vulnerabilities to the organization that is in the best position to address that vulnerability with a resolution. That organization is the "responsible organization."
      • If the responsible organization is not a CVE Partner, Rapid7 will reserve a CVE ID.
    2. After 15 days, Rapid7 will inform CERT/CC of the vulnerability with enough technical detail to demonstrate the issue. If the responsible organization has not acknowledged our initial disclosure by this time, Rapid7 will presume they are a "non-responsive responsible organization."
    3. After 60 days of confidential disclosure to the responsible organization, Rapid7 will publicly disclose vulnerability information, including CVE descriptions, opinions on risk, impact, and mitigation strategies, and enough technical detail to demonstrate the issue (collectively, "vulnerability details"). Rapid7 may involve media outlets in that disclosure.
      • During this 60 day window, Rapid7 expects the responsible organization will develop a resolution and make any update available for affected parties, and Rapid7 will keep CERT/CC apprised of the status of those updates.
      • If the responsible organization is showing consistent good-faith effort to develop and ship an update, but cannot complete this work within 60 days, a 30-day extension may be granted at Rapid7’s sole discretion under the Default Policy (or for any of the enumerated exceptions below).
    4. If Rapid7 becomes aware that an update was made generally available after reporting the issue to the responsible organization, including silent patches which tend to hijack CVD norms, Rapid7 will aim to publish vulnerability details within 24 hours.
    5. Issues that are confidentially rediscovered and reported to the responsible organization as duplicates have no bearing on the timeline expectations of this policy.

Exploited In the Wild
This is the case where we see active exploitation in a production environment, including our own. The goal in these situations is to release critical information about risk as quickly as possible so organizations may take informed action to protect themselves.

This policy is identical to the default policy but for these changes:

  • Rapid7 will aim to notify CERT/CC and publish public vulnerability information approximately 72 hours after discovery, regardless of the existence of an update.
  • If the vulnerability was found within an organization’s environment, Rapid7 will strive to notify directly affected organizations of the disclosure first.

Patch Bypasses
This is the case where a vendor believes they fixed an issue, but didn't.

This policy is identical to the Exploited In the Wild policy but for these changes:

  • A new CVE ID will be reserved that references the original CVE ID.
  • Rapid7 will inform the responsible organization and CERT/CC concurrently.
  • Depending on the nature of the bypass, Rapid7 may release vulnerability details immediately, or up to 45 days after reporting to CERT/CC.

Cloud/Hosted Vulnerabilities
This is the case where end users or implementors have nothing to fix on their end — fixing the issue requires only one responsible organization to act.

This policy is identical to the default policy but for these changes:

  • A CVE ID will not be reserved by Rapid7.
  • If the issue is resolved inside the 60 day coordination window, Rapid7 will assess the value of a public disclosure. If the issue remains unresolved after the coordination window closes, a public disclosure may be issued per the default policy.

Kinetic Vulnerabilities
These are vulnerabilities that have obvious and direct implications for human health and safety, and are not otherwise present in generally-used technology. Specialized OT and medical technology fall into this category.

Changes to the default:

  • Rapid7 will disclose vulnerability details 30 days after the general availability of the update, instead of immediately.
    • If the vulnerability becomes actively exploited in the wild, the Exploited in the Wild policy shall apply instead.
  • Rapid7 will coordinate with relevant government agencies that are in a position to work with the responsible organization to develop, distribute and implement updates (including CERT/CC).
  • Coordination with CERT/CC and the responsible organization may be extended for up to 180 days. If there is no update available after 180 days, Rapid7 will publish vulnerability details.

Low-Impact Vulnerabilities
These vulnerabilities are trivial enough that an exploit would cause safely ignorable consequences to affected production environments, or limited to a single production instance, such as one website not connected to critical infrastructure, or extant in only theoretical or very unlikely configurations of affected systems.

Changes to the default:

  • Rapid7 will not coordinate with CERT/CC.
  • Rapid7 may not publish vulnerability details at any point, but may do so if circumstances change (for example, if it's shown that this low-impact vulnerability can be chained with another to achieve a high-impact result).

Vulnerabilities with No Responsible Organization
These are vulnerabilities in obsolete systems, abandoned software packages, or maintained by non-responsive responsible organizations.

Changes to the default:

  • Rapid7 will publish vulnerability details 45 days after providing CERT/CC vulnerability details, or on a timeline that is agreed upon with CERT/CC.

Multi-Faceted Vulnerabilities
These vulnerabilities match more than one non-default category, such as a vulnerability for unsupported software that is exploited in the wild.

  • If there is a conflict in timelines, the shorter timeline shall apply.


If you have any questions about this policy, or coordinated vulnerability disclosure in general, please feel free to reach out to

You can also read our blog for more discussion on this policy.