<!--{
	"Title": "Go Security Policy",
	"layout": "article"
}-->

<h2 id="overview">Overview</h2>

<p>
  This document explains the Go Security team's process for handling issues
  reported and what to expect in return.
</p>

<h2 id="reporting">Reporting a Security Bug</h2>

<p>
  All security bugs in the Go distribution should be reported by email to
  <a href="mailto:security@golang.org">security@golang.org</a>. This mail is
  delivered to the Go Security team.
</p>

<p>
  To ensure your report is not marked as spam,
  <strong>please include the word "vulnerability"</strong> anywhere in your
  email. Please use a descriptive subject line for your report email.
</p>

<p>
  Your email will be acknowledged within 7 days, and you'll be kept up to date
  with the progress until resolution. Your issue will be fixed or made public
  within 90 days.
</p>
<p>
  If you have not received a reply to your email within 7 days,
  please follow up with the Go security team again at
  <a href="mailto:security@golang.org">security@golang.org</a>. Please make
  sure the word <strong>vulnerability</strong> is in your email.
</p>
<p>
  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 <a href="https://g.co/vulnz">file an issue here</a>.
  Select <i>"I want to report a technical security or an abuse risk related bug
  in a Google product (SQLi, XSS, etc.)"</i>, and list <i>"Go"</i> as the
  affected product.
</p>

<h2 id="tracks">Tracks</h2>

<p>
  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.
</p>

<h3 id="public">PUBLIC</h3>
<p>
  Issues in the PUBLIC track affect niche configurations, have very limited
  impact, or are already widely known.
</p>

<p>
  PUBLIC track issues are <strong>fixed in public</strong>, and get backported
  to the next scheduled
  <a href="/wiki/MinorReleases">minor releases</a>
  (which occur ~monthly). The release announcement includes details of these
  issues, but there is no pre-announcement.
</p>

<p>Examples of past PUBLIC issues include:</p>
<ul>
  <li>
    <a href="/issue/44916">#44916</a>:
    archive/zip: can panic when calling Reader.Open
  </li>
  <li>
    <a href="/issue/44913">#44913</a>:
    encoding/xml: infinite loop when using xml.NewTokenDecoder with a custom
    TokenReader
  </li>
  <li>
    <a href="/issue/43786">#43786</a>:
    encoding/xml: infinite crypto/elliptic: incorrect operations on the P-224
    curve
  </li>
  <li>
    <a href="/issue/40928">#40928</a>:
    net/http/cgi,net/http/fcgi: Cross-Site Scripting (XSS) when Content-Type is
    not specified
  </li>
  <li>
    <a href="/issue/40618">#40618</a>:
    encoding/binary: ReadUvarint and ReadVarint can read an unlimited number of
    bytes from invalid inputs
  </li>
  <li>
    <a href="/issue/36834">#36834</a>:
    crypto/x509: certificate validation bypass on Windows 10
  </li>
</ul>

<h3 id="private">PRIVATE</h3>

<p>
  Issues in the PRIVATE track are violations of committed security properties.
</p>

<p>
  PRIVATE track issues are
  <strong>fixed in the next scheduled
    <a href="/wiki/MinorReleases">minor releases</a>
  </strong>,
  and are kept private until then.
</p>

<p>
  Three to seven days before the release, a pre-announcement is sent to
  golang-announce, announcing the presence of a security fix in the upcoming
  releases, and whether the issue affects the standard library, the toolchain,
  or both (but not disclosing any more details).
</p>

<p>Some examples of past PRIVATE issues include:</p>
<ul>
  <li>
    <a href="/issue/42552">#42552</a>:
    math/big: panic during recursive division of very large numbers
  </li>
  <li>
    <a href="/issue/34902">#34902</a>:
    net/http: Expect 100-continue panics in httputil.ReverseProxy
  </li>
  <li>
    <a href="/issue/39360">#39360</a>:
    crypto/x509: Certificate.Verify method seemingly ignoring EKU requirements
    on Windows
  </li>
  <li>
    <a href="/issue/34960">#34960</a>:
    crypto/dsa: invalid public key causes panic in dsa.Verify
  </li>
  <li>
    <a href="/issue/34540">#34540</a>:
    net/http: invalid headers are normalized, allowing request smuggling
  </li>
  <li>
    <a href="/issue/29098">#29098</a>:
    net/url: URL.Parse Multiple Parsing Issues
  </li>
</ul>

<h3 id="urgent">URGENT</h3>

<p>
  URGENT track issues are a threat to the Go ecosystem’s integrity, or are being
  actively exploited in the wild leading to severe damage. There are no recent
  examples, but they would include remote code execution in net/http, or
  practical key recovery in crypto/tls.
</p>

<p>
  URGENT track issues are fixed in private, and
  <strong>trigger an immediate dedicated security release</strong>, possibly
  with no pre-announcement.
</p>

<h2 id="flagging">Flagging Existing Issues as Security-related</h2>

<p>
  If you believe that an <a href="/issue">existing issue</a>
  is security-related, we ask that you send an email to
  <a href="mailto:security@golang.org">security@golang.org</a>. The email should
  include the issue ID and a short description of why it should be handled
  according to this security policy.
</p>

<h2 id="disclosure">Disclosure Process</h2>

<p>The Go project uses the following disclosure process:</p>

<ol>
  <li>
    Once the security report is received it is assigned a primary handler. This
    person coordinates the fix and release process.
  </li>
  <li>The issue is confirmed and a list of affected software is determined.</li>
  <li>Code is audited to find any potential similar problems.</li>
  <li>
    If it is determined, in consultation with the submitter, that a CVE number is
    required, the primary handler will obtain one.
  </li>
  <li>
    Fixes are prepared for the two most recent major releases and the
    head/master revision. Fixes are prepared for the two most recent major
    releases and merged to head/master.
  </li>
  <li>
    On the date that the fixes are applied, announcements are sent to
    <a href="https://groups.google.com/group/golang-announce">golang-announce</a>,
    <a href="https://groups.google.com/group/golang-dev">golang-dev</a>, and
    <a href="https://groups.google.com/group/golang-nuts">golang-nuts</a>.
  </li>
</ol>

<p>
  This process can take some time, especially when coordination is required with
  maintainers of other projects. Every effort will be made to handle the bug in
  as timely a manner as possible, however it's important that we follow the
  process described above to ensure that disclosures are handled consistently.
</p>

<p>
  For security issues that include the assignment of a CVE number, the issue is
  listed publicly under the
  <a href="https://www.cvedetails.com/vulnerability-list/vendor_id-14185/Golang.html">
    "Golang" product on the CVEDetails website
  </a>
  as well as the
  <a href="https://web.nvd.nist.gov/view/vuln/search">
    National Vulnerability Disclosure site
  </a>.
</p>

<h2 id="updates">Receiving Security Updates</h2>

<p>
  The best way to receive security announcements is to subscribe to the
  <a href="https://groups.google.com/forum/#!forum/golang-announce">
    golang-announce
  </a>
  mailing list. Any messages pertaining to a security issue will be prefixed
  with <code>[security]</code>.
</p>

<h2 id="comments">Comments on This Policy</h2>

<p>
  If you have any suggestions to improve this policy, please
  <a href="/issue/new">file an issue</a> for discussion.
</p>