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

To report a vulnerability, please e-mail [email protected] with a description of the issue, the steps you took to create the issue, affected versions, and if known, mitigations for the issue.

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

We use GitHub's security advisory feature to track open security issues. You should expect a close collaboration as we work to resolve the issue 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 an issue, and avoid revealing information about vulnerabilities in public if that could put users at risk.

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, they will:

0. Reply to the e-mail acknowledging its receipt, cc'ing [email protected] so that the other members of the team are aware that they are handling the issue. If the e-mail does not describe an actual vulnerability, the process will stop here. (Unfortunately, we do receive spam at this address, as well as well-meaning but ultimately misguided reports that do not represent issues for which this process is appropriate.)
1. Create a new security advisory. One must be one of the repo admins 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.
2. Add the reporter to the security advisory so that they can get updates.
3. Reopen flutter/flutter#72555 to ensure that security vulnerabilities will be checked during critical triage.
4. Inform the relevant team lead, adding them to the security advisory.
5. If the security issue does not yet have a CVE number, they will, as a Googler, see go/cve-request to establish one.

As the fix is being developed, they will then 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.

When the issue is resolved, they will contact the release team and our PR team to coordinate the publication of the security advisory.

Security issues have the equivalent of a P0 priority level, but (other than via issue 72555) are not tracked explicitly in the issue database. This means that we attempt to fix them as quickly as possible.

For more information on security advisories, see the GitHub documentation.

If team members need additional help from Google, as a Googler, they can see go/vuln.