Go Security Policy - The Go Programming Language

Common problems companies solve with Go
Stories about how and why companies use Go
How Go can help keep you secure by default
The official Go language specification
A complete introduction to building software with Go
Reference documentation for Go's standard library
Learn what's new in each Go release
Tips for writing clear, performant, and idiomatic Go code
Videos from prior events
Meet other local Go developers
Learn and network with Go developers from around the world
The Go project's official blog.
Get help and stay informed from Go
This document explains the Go Security team’s process for handling issues reported and what to expect in return.
All security bugs in the Go distribution should be reported by email to security@golang.org. This mail is delivered to the Go Security team.
Please format the subject of your email as “Vulnerability: {package name}: {one-line summary}”, and avoid sending attachments in your email unless strictly necessary in order to avoid your message being marked as spam. Additionally, please send one report per email.
If desired, please include your preferred attribution as part of the report. This attribution will be added to the CVE, if one is published.
Please keep reports succinct, including a description of the issue you’ve found, the way in which you believe it can be exploited, and a small reproduction test case or program which demonstrates the issue.
We have a list of decisions about commonly-reported categories of issues.
Your email will be acknowledged within 7 days. If you have not received a reply by then, please follow up with the Go Security team again at security@golang.org. Please make sure the word vulnerability is in your email.
If after 3 more days you have still not received an acknowledgement of your report, it is possible that your email might have been marked as spam. In that case, please file an issue here. Select “I want to report a technical security or an abuse risk related bug in a Google product (SQLi, XSS, etc.)”, and list “Go” as the affected product.
Your issue will be fixed or made public within 90 days after our initial acknowledgement.
Emails reporting security issues will be retained indefinitely to track remediation status and correctly attribute discoveries.
Please do not send LLM-generated reports without proper curation.
Modern LLMs are very good at finding real and important security bugs. Unfortunately, they are also very good at finding imaginary issues, or real issues that are not security bugs. LLM output is often verbose, buries important information in irrelevant text, and contains grandiose and unsupportable claims.
For LLM-generated reports, the value lies in curation. Sending us dozens of possible security issues while relying on us to find the one significant result hidden among them asks us to do the curation, and ultimately hinders our goal of making Go secure. For this reason, we only attribute discoveries to reporters with a substantial percentage of real findings.
While there are no hard and fast rules, as a general guideline, if most of your reports are not designated as security issues, and we do not believe that you are providing useful curation, we will not credit you for any discoveries in the remainder. We deliberately do not define a concrete threshold for “most” or what “curation” entails. However, our intent is that a good-faith reporter providing meaningful value will always receive credit, while a reporter forwarding large quantities of LLM output indiscriminately will not.
Depending on the nature of your issue, it will be categorized by the Go Security team as an issue in the PUBLIC, PRIVATE, or URGENT track. All security issues will be issued CVE numbers.
The Go Security team does not assign traditional fine-grained severity labels (e.g CRITICAL, HIGH, MEDIUM, LOW) to security issues because severity depends highly on how a user is using the affected API or functionality. Additionally, when issuing CVEs for Go security issues we do not assign CVSS scores, as we fundamentally disagree with the applicability of the scoring system to Go for the same reasons. Third parties, such as MITRE or NIST, via the NVD, may assign CVSS scores to our vulnerabilities, but we do not endorse these scores as accurate reflections of their impact.
For example, the impact of a resource exhaustion issue in the encoding/json parser depends on what is being parsed. If the user is parsing trusted JSON files from their local filesystem, the impact is likely to be low. If the user is parsing untrusted arbitrary JSON from an HTTP request body, the impact may be much higher.
That said, the following issue tracks do signal how severe and/or wide-reaching the Security team believes an issue to be. For example, an issue with medium to significant impact for many users is a PRIVATE track issue in this policy, and an issue with negligible to minor impact, or which affects only a small subset of users, is a PUBLIC track issue.
Issues in the PUBLIC track affect niche configurations, have very limited impact, or are already widely known.
PUBLIC track issues are labeled with Proposal-Security, discussed through the Go proposal review process fixed in public, and get backported to the next scheduled minor releases (which occur ~monthly). The release announcement includes details of these issues, but there is no pre-announcement.
Examples of past PUBLIC issues include:
Issues in the PRIVATE track are violations of committed security properties.
PRIVATE track issues are fixed in the next scheduled minor releases, and are kept private until then.
Three to seven days before the release, a pre-announcement is sent to golang-announce, announcing the presence of one or more security fixes in the upcoming releases, and whether the issues affect the standard library, the toolchain, or both, as well as reserved CVE IDs for each of the fixes.
For issues that are present in a major version release candidate, we follow the same process, incl