We commit to publishing security updates for the version of Flutter currently on the stable branch.

We treat security reports equivalent to a P0 priority level. This means that we attempt to fix them as quickly as possible. We will release a beta or hotfix for any major security report found in the most recent stable version of our SDK.

Any vulnerability reported for any Flutter websites like flutter.dev does not require a release and will be fixed in the website itself.

To report a vulnerability, please e-mail [email protected] with a description of the problem, the steps you took to reproduce the problem, affected versions and any known mitigations.

We should reply within three working days, probably much sooner.

We use GitHub's security advisory feature to track open security reports. You should expect a close collaboration as we work to resolve the security vulnerability you have reported. Please reach out to [email protected] again if you do not receive prompt attention and regular updates.

You may also reach out to the team via our public Discord chat channels; however, please make sure to e-mail [email protected] when reporting a vulnerability, and avoid revealing information about vulnerabilities in public if that could put users at risk.

If you believe that an existing github issue is security-related, we ask that you send an email to [email protected]. The email should include the github issue ID and a short description of why it should be handled according to this security policy.

Security reports are not tracked explicitly in the github issue database (other than via issue 72555).

This section describes the process used by the Flutter team when handling vulnerability reports.

Vulnerability reports are received via the [email protected] e-mail alias. Certain team members who have been designated the "vulnerability management team" receive these e-mails. When receiving such an e-mail, one of the vulnerability management team members will:

1. Reply to the email acknowledging its receipt, cc'ing [email protected] so that the other members of the team are aware that they are handling the security report. If the email does not describe an actual vulnerability, the process will stop here. (Unfortunately, we do receive spam, and well-meaning but ultimately misguided reports that do not represent issues for which this process is appropriate, at this address.)
2. Triage the report to evaluate its impact and if it is a security vulnerability.
3. Collaborate with the appropriate team lead to ensure that an owner is assigned to the report. The owner will drive it through the fix and release process.
4. Work with the team lead and product manager to determine if this security report requires a security advisory.
5. Create a new security advisory if an advisory is required. One must be the repo admin to do this. Vulnerability management team members who are not also a repo admin will reach out to the repo admins until they find one who can create the advisory. The repo admins who are also vulnerability management team members are @Hixie and @tvolkert.
6. Reach out to the reporter to ask them if they would like to be involved and whether they would like to be credited. For credit, the GitHub security advisory UI has a field that allows contributors to be credited.
7. Add the vulnerability reporter, relevant team lead and fix owner to the security advisory so that they can get updates.
8. If the security issue does not yet have a CVE number, as a Googler, request one from go/cve-request. Every security advisory will have a CVE number.
9. Reopen Issue 72555 to ensure that security vulnerabilities will be checked during critical triage.
10. Work with the release and PR team to coordinate the publication of the security advisory.

The best way to receive security updates is to subscribe to the flutter-announce mailing list or updates to the Discord channel. We will also announce security advisories in the technical release blog post.

Flutter does not have a bug bounty program.

• If team members need additional help, as a Googler they can review Dash Security Playbook
• For more information on security advisories, see the GitHub documentation.

If team members from other organizations would like their team's playbook listed here for their reference (even if it is not a public resource), please submit a PR.