FIRST bug bounty program
FIRST encourages security researchers to disclose security vulnerabilities in our services to FIRST in a responsible way. We support independent security research. Security evaluations must:
- Be performed on the *.first.org domain;
- Not be performed on the sites of letsencrypt.org, UltraDNS, T3 systems or any of the services these vendors operate for FIRST. If you inadvertently find an issue while using these services on FIRST.org, we’d like to hear about it. However, we cannot provide permission to test these third parties.
- Not compromise the security or privacy of FIRST members, or the data on our systems;
- Not destroy information or affect the availability of our services;
- Not involve social engineering or evaluate the physical security controls around our systems.
Please send any issues you identify to [email protected] and include "security vulnerability" in the subject line. We appreciate it if you could include the following information:
- Your contact information, so we can follow up with questions;
- A description of the issue and its nature;
- Detailed steps that allow us to reproduce the issue;
- A brief description of the security impact of the issue.
Please specify if we may publicly credit you on this page.
As a non-profit, we can’t pay out major bounties, but we really appreciate your help in helping safeguard our systems. If we confirm your finding as a vulnerability, we will send you a token of our appreciation.
Hall of fame
2017
- Eslam Mohamed Reda - found a CSRF vulnerability in the login and sign in page. It was solved by replacing the old framework / website with a new one (which was planned anyway).
2016
- Dinar Gataullin - found a bug in the CVSS calculator. This was inside an outdated JS library.
Note well
- Reports of vulnerabilities by researchers based in sanctioned countries. We’re terribly sorry, but for legal reasons we cannot ship any token of appreciation to countries on various sanctions lists, such as Iran, North Korea and Syria. A full list of sanctioned entities can be found on the site of the US Department of Treasury. We will be happy to fix your report, and list you in our Hall of Fame, though. As a US incorporated organisation we are bound to local laws.
- Logout CSRF: CSRF vulnerabilities whose maximum impact is for the user to log out of the authenticated part of our web sites are difficult to defend against and don’t expose customer data to risk, hence they are out of scope for our program.
- Presence of banner or version information: for various reasons, we may determine to mask the version of a daemon, or not do so to ensure the service is more predictable. If the service isn’t vulnerable to an issue, we do not consider simply learning its version a security vulnerability.
- Configurations which are explicitly stated in policy: for instance, for some of our domains, we may monitor for policy violations, rather than block them. An example is softfail SPF and DKIM.
