Vulnerability Reports & Disclosure

Owned by Renata Pereira Juraski
Last updated: Jul 22, 2024 by Julio
2 min read

Responsible Disclosure

We have an established Vulnerability Management program that handles all layers of our application and infrastructure by using different data sources, including our bug bounty program, external and internal penetration tests, automated tooling, support channels, and so forth.

It is important that all security researchers who want to report vulnerabilities to Rocket.Chat follow this policy. By doing so, there’s a guarantee that security issues are being shared privately and will remain so until a fix is released.

If you have any suggestions or questions about this process, feel free to email us at security@rocket.chat.

Bug Bounty / HackerOne

HackerOne is a service that allows us to interact with independent security researchers to collect, manage and disclose vulnerabilities that are discovered by them. HackerOne is managed by the Security Team, but all members of Rocket.Chat can request access if they want or need to collaborate directly with the external party.

HackerOne runs parallel to Jira, which is used for internal collaboration - however, HackerOne reports must be linked to Jira issues as per our vulnerability management process.

GitHub Issues

If the vulnerability was reported via a public issue, we may remove it and refer the reporter to our email address or HackerOne. We will still open a Jira issue and track it internally.

The deletion of the issue may happen because, depending on the severity of the vulnerability, attackers may use it to exploit Rocket.Chat servers in the wild until a fix is released.

Vulnerabilities SLA

For all reported vulnerabilities, regardless of source, reporters should expect a first-response time of up to 5 (five) business days.

Our current SLA to deal with vulnerabilities are:

  • Critical: 14 days

  • High: 30 days

  • Medium: 60 days

  • Low: Best effort unless risk accepted

More information about our Vulnerability Management process can be found here.

CVE IDs

We use CVE IDs to uniquely identify and publicly define vulnerabilities in our products. CVEs will always be obtained for critical and high-severity vulnerabilities, while medium and low vulnerabilities will have their relevance evaluated before requesting a CVE.

Keep in mind that some of our security releases contain security related enhancements which may not have an associated CWE or vulnerability. These particular issues are not required to obtain a CVE.

The Security Team currently requests CVEs either through the HackerOne form (preferred) or directly through MITRE's webform.