Follow-up to 4210ba07d9, which added the
"tool" directive, but kept the existing package references, which means
that installation would potentially happen multiple times.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This release include 3 security fixes following the security policy:
- mime: quadratic complexity in WordDecoder.DecodeHeader
Decoding a maliciously-crafted MIME header containing many invalid
encoded-words could consume excessive CPU.
The MIME decoder now better handles this case.
Thanks to p4p3r (https://hackerone.com/p4p3r_hak) for reporting this issue.
This is CVE-2026-42504 and Go issue https://go.dev/issue/79217.
- net/textproto: arbitrary input are included in errors without any escaping
When returning errors, functions in the net/textproto package would
include its input as part of the error, without any escaping. Note that
said input is often controlled by external parties when using this
package naturally. For example, a net/http client uses ReadMIMEHeader
when parsing the headers it receive from a server.
As a result, an attacker could inject arbitrary content into the error.
Practically, this can result in an attacker injecting misleading
content, terminal control bytes, etc. into a victim's output or logs.
This is CVE-2026-42507 and Go issue https://go.dev/issue/79346
- crypto/x509: split candidate hostname only once
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop
over all DNS Subject Alternative Name (SAN) entries. This caused
strings.Split(host, ".") to execute repeatedly on the same input hostname.
With a large DNS SAN list, verification costs scaled quadratically based on the
number of SAN entries multiplied by the hostname's label count. Because
x509.Verify validates hostnames before building the certificate chain, this
overhead occurred even for untrusted certificates.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-27145 and https://go.dev/issue/79694.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.26.4
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This release include 11 security fixes:
- cmd/go: malicious module proxy can bypass checksum database
A malicious module proxy could exploit a flaw in the go command's
validation of module checksums to bypass checksum database validation.
This vulnerability affects any user using an untrusted module proxy
(GOMODPROXY) or checksum database (GOSUMDB).
A malicious module proxy can serve altered versions of the Go toolchain.
When selecting a different version of the Go toolchain than the
currently installed toolchain (due to the GOTOOLCHAIN environment variable,
or a go.work or go.mod with a toolchain line), the go command will download
and execute a toolchain provided by the module proxy. A malicious module
proxy can bypass checksum database validation for this downloaded
toolchain.
Since this vulnerability affects the security of toolchain downloads,
setting GOTOOLCHAIN to a fixed version is not sufficient. You must upgrade
your base Go toolchain.
The go tool always validates the hash of a toolchain before executing it,
so fixed versions will refuse to execute any cached, altered versions of the
toolchain.
The go tool trusts go.sum files to contain accurate hashes of the current
module's dependencies. A malicious proxy exploiting this vulnerability to
serve an altered module will have caused an incorrect hash to be recorded
in the go.sum. Users who have configured a non-trusted GOPROXY can determine
if they have been affected by running "rm go.sum ; go mod tidy ; go mod verify",
which will revalidate all dependencies of the current module.
The specific flaw in more detail:
The go command consults the checksum database to validate downloaded modules,
when a module is not listed in the go.sum file. It verifies that the module hash
reported by the checksum database matches the hash of the downloaded module.
If, however, the checksum database returns a successful response that contains
no entry for the module, the go command incorrectly permitted validation to succeed.
A module proxy may mirror or proxy the checksum database, in which case the go
command will not connect to the checksum database directly. Checksums reported
by the checksum database are cryptographically signed, so a malicious proxy
cannot alter the reported checksum for a module. However, a proxy which returns
an empty checksum response, or a checksum response for an unrelated module,
could cause the go command to proceed as if a downloaded module has been validated.
The go command now properly checks checksum database responses to ensure
that the expected module signature is present, not just that if a signature is
present it matches the expectation.
Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue.
This is CVE-2026-42501 and Go issue https://go.dev/issue/79070.
- net/http/httputil: ReverseProxy forwards queries with more than urlmaxqueryparams parameters
When used with a Rewrite function, or a Director function which parses query parameters,
ReverseProxy sanitizes the forwarded request to remove query parameters which are not
parsed by url.ParseQuery. ReverseProxy did not take ParseQuery's limit on the total number
of query parameters (controlled by GODEBUG=urlmaxqueryparams=N) into account.
This could permit ReverseProxy to forward a request containing a query parameter
that was not visible to the Rewrite function.
For example, the query "a1=x&a2=x&...&a10000=x&hidden=y" could forward the parameter
"hidden=y" while hiding it from the proxy's Rewrite function.
ReverseProxy now avoids forwarding parameters that exceed the ParseQuery limit.
This is CVE-2026-39825 and Go issue https://go.dev/issue/78948.
- net: panic in Dial and LookupPort when handling NUL byte on Windows
The Dial and LookupPort functions would panic on Windows when provided
with an input containing a NUL (0). These functions now return an error
rather than panicking.
This is CVE-2026-39836 and Go issue https://go.dev/issue/79006.
- net/mail: quadratic string concatenation in consumePhrase
Pathological inputs could cause DoS through consumePhrase
when parsing an email address according to RFC 5322.
This is CVE-2026-42499 and Go issue https://go.dev/issue/78987.
- net/mail: quadratic string concatentation in consumeComment
Well-crafted inputs reaching ParseAddress, ParseAddressList,
and ParseDate were able to trigger excessive CPU exhaustion
and memory allocations.
This is CVE-2026-39820 and Go issue https://go.dev/issue/78566.
- cmd/go: "go bug" follows symlinks in predictable temporary filenames
The "go bug" command wrote to two files with predictable names in
the system temporary directory (for example, "/tmp").
An attacker with access to the temporary directory could create a
symlink in one of these names, causing "go bug" to overwrite the
target of the symlink.
The "go bug" command now uses os.MkdirTemp to create a safe
working directory.
Thanks to Harshit Gupta (Mr HAX) for reporting this issue.
This is CVE-2026-39819 and Go issue https://go.dev/issue/78584.
- cmd/go: "go tool pack" does not sanitize output paths
The "go tool pack" subcommand is a minimal version of the Unix ar utility.
It is used by the compiler as an internal tool with known-good inputs.
The "pack" subcommand did not sanitize output filenames.
When invoked to extract a malicious archive file, it could write
files to arbitrary locations on the filesystem.
The "pack" subcommand now refuses to extract files with names
containing any directory components.
Thanks to Harshit Gupta (Mr HAX) for reporting this issue.
This is CVE-2026-39817 and Go issue https://go.dev/issue/78778.
- net/http: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of
writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a
value of 0.
This allows potential DoS against a client by a malicious server. HTTP/2
transport now properly checks that the received SETTINGS_MAX_FRAME_SIZE is
valid.
Thanks to Marwan Atia (marwansamir688@gmail.com) for reporting this issue.
This is CVE-2026-33814 and Go issue https://go.dev/issue/78476.
- html/template: escaper bypass leads to XSS
If a trusted template author were to write a
tag containing an empty type attribute or a type
attribute with an ASCII whitespace, the execution of
the template would incorrectly escape any data passed
into the block.
Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue.
This is CVE-2026-39826 and Go issue https://go.dev/issue/78981.
- net: crash when handling long CNAME response
When using LookupCNAME with the cgo DNS resolver,
a very long CNAME response could trigger a double-free of C memory
and a crash. The double-free has been fixed.
Thanks to hamayanhamayan for reporting this issue.
This is CVE-2026-33811 and Go issue https://go.dev/issue/78803.
- html/template: bypass of meta content URL escaping causes XSS
CVE-2026-27142 fixed a vulnerability in which URLs were not
correctly escaped inside of a tag's attribute.
If the URL content were to insert ASCII whitespaces around the
= rune inside of the attribute, the escaper would
fail to similarly escape it, leading to XSS.
Dynamic inputs to a tag's attribute are now
whitespace sanitized prior to escaping.
Thanks to Samy Ghannad for reporting this issue.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.26.2 (released 2026-04-07) includes security fixes to the go command,
the compiler, and the archive/tar, crypto/tls, crypto/x509, html/template,
and os packages, as well as bug fixes to the go command, the go fix command,
the compiler, the linker, the runtime, and the net, net/http, and net/url
packages. See the Go 1.26.2 milestone on our issue tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.26.2+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.26.1...go1.26.2
From the security announce:
We have just released Go versions 1.26.2 and 1.25.9, minor point releases.
These releases include 10 security fixes following the security policy:
- os: Root.Chmod can follow symlinks out of the root on Linux
On Linux, if the target of Root.Chmod is replaced with a symlink while
the chmod operation is in progress, Chmod could operate on the target
of the symlink, even when the target lies outside the root.
The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag,
which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its
target before acting and returns an error if the target is a symlink
lying outside the root, so the impact is limited to cases where the
target is replaced with a symlink between the check and operation.
On Linux, Root.Chmod now uses the fchmodat2 syscall when available, and
an workaround using /proc/self/fd otherwise.
Thanks to Uuganbayar Lkhamsuren for reporting this issue.
This is CVE-2026-32282 and Go issue https://go.dev/issue/78293.
- html/template: JS template literal context incorrectly tracked
Context was not properly tracked across template branches for JS template
literals, leading to possibly incorrect escaping of content when branches were
used.
Additionally template actions within JS template literals did not properly
track
the brace depth, leading to incorrect escaping being applied.
These issues could cause actions within JS template literals to be incorrectly
or improperly escaped, leading to XSS vulnerabilities.
This only affects templates that use template actions within JS template
literals.
This is CVE-2026-32289 and Go issue https://go.dev/issue/78331.
- crypto/x509: excluded DNS constraints not properly applied to wildcard domains
When verifying a certificate chain containing excluded DNS constraints, these
constraints are not correctly applied to wildcard DNS SANs which use a
different
case than the constraint.
For example, if a certificate contains the DNS name "*.example.com" and the
excluded DNS name "EXAMPLE.COM", the constraint will not be applied.
This only affects validation of otherwise trusted certificate chains, issued
by
a root CA in the VerifyOptions.Roots CertPool, or in the system certificate
pool.
This issue only affects Go 1.26.
Thank you to Riyas from Saintgits College of Engineering, k1rnt, @1seal for
reporting this issue.
This is CVE-2026-33810 and Go issue https://go.dev/issue/78332.
- cmd/compile: no-op interface conversion bypasses overlap checking
Previously, the compiler failed to unwrap pointers contained within
a no-op interface conversion leading to an incorrect determination
of a non-overlapping move.
To prevent unsafe move operations, the compiler will now unwrap all
such conversions before considering a move non-overlapping.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-27144 and Go issue https://go.dev/issue/78371.
- cmd/compile: possible memory corruption after bound check elimination
Previously, slices and arrays accessed using induction variables
were sometimes incorrectly proved in-bound. If the induction variable
used for indexing were to overflow or underflow, it could allow access
to memory beyond the scope of the original slice or array.
To prevent this behavior, the compiler ensures that any mutated induction
variable that overflows/underflows with respect to its loop condition
is not used for bound check elimination.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-27143 and Go issue https://go.dev/issue/78333.
- archive/tar: unbounded allocation when parsing old format GNU sparse map
tar.Reader could allocate an unbounded amount of memory when reading
a maliciously-crafted archive containing a large number of sparse
regions encoded in the "old GNU sparse map" format.
We now limit both the number of old GNU sparse map extension blocks,
and the total number of sparse file entries, regardless of encoding.
Thanks to Colin Walters (wal...@verbum.org) who initially reported this issue.
Thanks also to Uuganbayar Lkhamsuren (https://github.com/uug4na) and Jakub
Ciolek
who additionally reported this issue.
This is CVE-2026-32288 and Go issue https://go.dev/issue/78301.
- crypto/tls: multiple key update handshake messages can cause connection to
deadlock
If one side of the TLS connection sends multiple key update messages
post-handshake in a single record, the connection can deadlock, causing
uncontrolled consumption of resources. This can lead to a denial of service.
This only affects TLS 1.3.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-32283 and Go issue https://go.dev/issue/78334.
- cmd/go: trust layer bypass when using cgo and SWIG
A well-crafted SWIG source file could take advantage
of a file-naming convention used inside the trust
boundary of the cgo compiler. Doing so could result
in arbitrary code execution during build time.
SWIG files are disallowed from using this convention.
Thank you to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2026-27140 and Go issue https://go.dev/issue/78335.
- crypto/x509: unexpected work during chain building
During chain building, the amount of work that is done is not correctly
limited
when a large number of intermediate certificates are passed in
VerifyOptions.Intermediates, which can lead to a denial of service. This
affects
both direct users of crypto/x509 and users of crypto/tls.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-32280 and Go issue https://go.dev/issue/78282.
- crypto/x509: inefficient policy validation
Validating certificate chains which use policies is unexpectedly inefficient
when certificates in the chain contain a very large number of policy mappings,
possibly causing denial of service.
This only affects validation of otherwise trusted certificate chains, issued
by
a root CA in the VerifyOptions.Roots CertPool, or in the system certificate
pool.
Thank you to Jakub Ciolek - https://ciolek.dev/ for reporting this issue.
This is CVE-2026-32281 and Go issue https://go.dev/issue/78281.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.25.8 (released 2026-03-05) includes security fixes to the html/template,
net/url, and os packages, as well as bug fixes to the go command, the compiler,
and the os package. See the Go 1.25.8 milestone on our issue tracker for details.
- 1.25.8 https://github.com/golang/go/issues?q=milestone%3AGo1.25.8+label%3ACherryPickApproved
- diff: https://github.com/golang/go/compare/go1.25.7...go1.25.8
- 1.26.1 https://github.com/golang/go/issues?q=milestone%3AGo1.26.1+label%3ACherryPickApproved
- diff: https://github.com/golang/go/compare/go1.26.0...go1.26.1
---
We have just released Go versions 1.26.1 and 1.25.8, minor point releases.
These releases include 5 security fixes following the security policy:
crypto/x509: incorrect enforcement of email constraints
- When verifying a certificate chain which contains a certificate containing
multiple email address constraints (composed of the full email address) which
share common local portions (the portion of the address before the '@'
character) but different domain portions (the portion of the address after the
'@' character), these constraints will not be properly applied, and only the
last constraint will be considered.
This can allow certificates in the chain containing email addresses which are
either not permitted or excluded by the relevant constraints to be returned by
calls to Certificate.Verify. Since the name constraint checks happen after chain
building is complete, this only applies to certificate chains which chain to
trusted roots (root certificates either in VerifyOptions.Roots or in the system
root certificate pool), requiring a trusted CA to issue certificates containing
either not permitted or excluded email addresses.
This issue only affects Go 1.26.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2026-27137 and Go issue https://go.dev/issue/77952.
- crypto/x509: panic in name constraint checking for malformed certificates
Certificate verification can panic when a certificate in the chain has an empty
DNS name and another certificate in the chain has excluded name constraints.
This can crash programs that are either directly verifying X.509 certificate
chains, or those that use TLS.
Since the name constraint checks happen after chain building is complete, this
only applies to certificate chains which chain to trusted roots (root
certificates either in VerifyOptions.Roots or in the system root certificate
pool), requiring a trusted CA to issue certificates containing malformed DNS
names.
This issue only affects Go 1.26.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2026-27138 and Go issue https://go.dev/issue/77953.
- html/template: URLs in meta content attribute actions are not escaped
Actions which insert URLs into the content attribute of HTML meta tags are not
escaped. This can allow XSS if the meta tag also has an http-equiv attribute
with the value "refresh".
A new GODEBUG setting has been added, htmlmetacontenturlescape, which can be
used to disable escaping URLs in actions in the meta content attribute which
follow "url=" by setting htmlmetacontenturlescape=0.
This is CVE-2026-27142 and Go issue https://go.dev/issue/77954.
- net/url: reject IPv6 literal not at start of host
The Go standard library function net/url.Parse insufficiently
validated the host/authority component and accepted some invalid URLs
by effectively treating garbage before an IP-literal as ignorable.
The function should have rejected this as invalid.
To prevent this behavior, net/url.Parse now rejects IPv6 literals
that do not appear at the start of the host subcomponent of a URL.
Thanks to Masaki Hara (https://github.com/qnighy) of Wantedly.
This is CVE-2026-25679 and Go issue https://go.dev/issue/77578.
- os: FileInfo can escape from a Root
On Unix platforms, when listing the contents of a directory using
File.ReadDir or File.Readdir the returned FileInfo could reference
a file outside of the Root in which the File was opened.
The contents of the FileInfo were populated using the lstat system
call, which takes the path to the file as a parameter. If a component
of the full path of the file described by the FileInfo is replaced with
a symbolic link, the target of the lstat can be directed to another
location on the filesystem.
The impact of this escape is limited to reading metadata provided by
lstat from arbitrary locations on the filesystem. This could be used
to probe for the presence or absence of files as well as gleaning
metadata like file sizes, but does not permit reading or writing files
outside the root.
The FileInfo is now populated using fstatat.
Thank you to Miloslav Trmač of Red Hat for reporting this issue.
This is CVE-2026-27139 and Go issue https://go.dev/issue/77827.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.25.7 (released 2026-02-04) includes security fixes to the go command
and the crypto/tls package, as well as bug fixes to the compiler and the
crypto/x509 package. See the Go 1.25.7 milestone on our issue tracker for
details:
https://github.com/golang/go/issues?q=milestone%3AGo1.25.7+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.25.6...go1.25.7
From the security mailing list:
> Hello gophers,
>
> We have just released Go versions 1.25.7 and 1.24.13, minor point releases.
>
> These releases include 2 security fixes following the security policy:
>
> - cmd/cgo: remove user-content from doc strings in cgo ASTs
>
> A discrepancy between how Go and C/C++ comments
> were parsed allowed for code smuggling into the
> resulting cgo binary.
>
> To prevent this behavior, the cgo compiler
> will no longer parse user-provided doc
> comments.
>
> Thank you to RyotaK (https://ryotak.net) of
> GMO Flatt Security Inc. for reporting this issue.
>
> This is CVE-2025-61732 and https://go.dev/issue/76697.
>
> - crypto/tls: unexpected session resumption when using Config.GetConfigForClient
>
> Config.GetConfigForClient is documented to use the original Config's session
> ticket keys unless explicitly overridden. This can cause unexpected behavior if
> the returned Config modifies authentication parameters, like ClientCAs: a
> connection initially established with the parent (or a sibling) Config can be
> resumed, bypassing the modified authentication requirements.
>
> If ClientAuth is VerifyClientCertIfGiven or RequireAndVerifyClientCert (on the
> server) or InsecureSkipVerify is false (on the client), crypto/tls now checks
> that the root of the previously-verified chain is still in ClientCAs/RootCAs
> when resuming a connection.
>
> Go 1.26 Release Candidate 2, Go 1.25.6, and Go 1.24.12 had fixed a similar issue
> related to session ticket keys being implicitly shared by Config.Clone. Since
> this fix is broader, the Config.Clone behavior change has been reverted.
>
> Note that VerifyPeerCertificate still behaves as documented: it does not apply
> to resumed connections. Applications that use Config.GetConfigForClient or
> Config.Clone and do not wish to blindly resume connections established with the
> original Config must use VerifyConnection instead (or SetSessionTicketKeys or
> SessionTicketsDisabled).
>
> Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
>
> This updates CVE-2025-68121 and Go issue https://go.dev/issue/77217.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This releases includes 6 security fixes following the security policy:
- archive/zip: denial of service when parsing arbitrary ZIP archives
archive/zip used a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.
Thanks to Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61728 and Go issue https://go.dev/issue/77102.
- net/http: memory exhaustion in Request.ParseForm
When parsing a URL-encoded form net/http may allocate an unexpected amount of
memory when provided a large number of key-value pairs. This can result in a
denial of service due to memory exhaustion.
Thanks to jub0bs for reporting this issue.
This is CVE-2025-61726 and Go issue https://go.dev/issue/77101.
- crypto/tls: Config.Clone copies automatically generated session ticket keys, session resumption does not account for the expiration of full certificate chain
The Config.Clone methods allows cloning a Config which has already been passed
to a TLS function, allowing it to be mutated and reused.
If Config.SessionTicketKey has not been set, and Config.SetSessionTicketKeys has
not been called, crypto/tls will generate random session ticket keys and
automatically rotate them. Config.Clone would copy these automatically generated
keys into the returned Config, meaning that the two Configs would share session
ticket keys, allowing sessions created using one Config could be used to resume
sessions with the other Config. This can allow clients to resume sessions even
though the Config may be configured such that they should not be able to do so.
Config.Clone no longer copies the automatically generated session ticket keys.
Config.Clone still copies keys which are explicitly provided, either by setting
Config.SessionTicketKey or by calling Config.SetSessionTicketKeys.
This issue was discoverd by the Go Security team while investigating another
issue reported by Coia Prant (github.com/rbqvq).
Additionally, on the server side only the expiration of the leaf certificate, if
one was provided during the initial handshake, was checked when considering if a
session could be resumed. This allowed sessions to be resumed if an intermediate
or root certificate in the chain had expired.
Session resumption now takes into account of the full chain when determining if
the session can be resumed.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2025-68121 and Go issue https://go.dev/issue/77113.
- cmd/go: bypass of flag sanitization can lead to arbitrary code execution
Usage of 'CgoPkgConfig' allowed execution of the pkg-config
binary with flags that are not explicitly safe-listed.
To prevent this behavior, compiler flags resulting from usage
of 'CgoPkgConfig' are sanitized prior to invoking pkg-config.
Thank you to RyotaK (https://ryotak.net) of GMO Flatt Security Inc.
for reporting this issue.
This is CVE-2025-61731 and go.dev/issue/77100.
- cmd/go: unexpected code execution when invoking toolchain
The Go toolchain supports multiple VCS which are used retrieving modules and
embedding build information into binaries.
On systems with Mercurial installed (hg) downloading modules (e.g. via go get or
go mod download) from non-standard sources (e.g. custom domains) can cause
unexpected code execution due to how external VCS commands are constructed.
On systems with Git installed, downloading and building modules with malicious
version strings could allow an attacker to write to arbitrary files on the
system the user has access to. This can only be triggered by explicitly
providing the malicious version strings to the toolchain, and does not affect
usage of @latest or bare module paths.
The toolchain now uses safer VCS options to prevent misinterpretation of
untrusted inputs. In addition, the toolchain now disallows module version
strings prefixed with a "-" or "/" character.
Thanks to splitline (@splitline) from DEVCORE Research Team for reporting this
issue.
This is CVE-2025-68119 and Go issue https://go.dev/issue/77099.
- crypto/tls: handshake messages may be processed at the incorrect encryption level
During the TLS 1.3 handshake if multiple messages are sent in records that span
encryption level boundaries (for instance the Client Hello and Encrypted
Extensions messages), the subsequent messages may be processed before the
encryption level changes. This can cause some minor information disclosure if a
network-local attacker can inject messages during the handshake.
Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.
This is CVE-2025-61730 and Go issue https://go.dev/issue/76443
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.6
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
These releases include 2 security fixes following the security policy:
- crypto/x509: excessive resource consumption in printing error string for host certificate validation
Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out.
Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime.
Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.
HostnameError.Error() now limits the number of hosts and utilizes strings.Builder when constructing an error string.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61729 and Go issue https://go.dev/issue/76445.
- crypto/x509: excluded subdomain constraint does not restrict wildcard SANs
An excluded subdomain constraint in a certificate chain does not restrict the
usage of wildcard SANs in the leaf certificate. For example a constraint that
excludes the subdomain test.example.com does not prevent a leaf certificate from
claiming the SAN *.example.com.
This is CVE-2025-61727 and Go issue https://go.dev/issue/76442.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This release addresses breakage caused by a security patch included in
Go 1.25.2 and 1.24.8, which enforced overly restrictive validation on
the parsing of X.509 certificates. We've removed those restrictions
while maintaining the security fix that the initial release addressed.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This minor release includes 10 security fixes following the security policy:
- net/mail: excessive CPU consumption in ParseAddress
The ParseAddress function constructed domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this could cause excessive CPU consumption.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61725 and Go issue https://go.dev/issue/75680.
- crypto/x509: quadratic complexity when checking name constraints
Due to the design of the name constraint checking algorithm, the processing time
of some inputs scales non-linearly with respect to the size of the certificate.
This affects programs which validate arbitrary certificate chains.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58187 and Go issue https://go.dev/issue/75681.
- crypto/tls: ALPN negotiation errors can contain arbitrary text
The crypto/tls conn.Handshake method returns an error on the server-side when
ALPN negotation fails which can contain arbitrary attacker controlled
information provided by the client-side of the connection which is not escaped.
This affects programs which log these errors without any additional form of
sanitization, and may allow injection of attacker controlled information into
logs.
Thanks to National Cyber Security Centre Finland for reporting this issue.
This is CVE-2025-58189 and Go issue https://go.dev/issue/75652.
- encoding/pem: quadratic complexity when parsing some invalid inputs
Due to the design of the PEM parsing function, the processing time for some
inputs scales non-linearly with respect to the size of the input.
This affects programs which parse untrusted PEM inputs.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61723 and Go issue https://go.dev/issue/75676.
- net/url: insufficient validation of bracketed IPv6 hostnames
The Parse function permitted values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.
Thanks to Enze Wang, Jingcheng Yang and Zehui Miao of Tsinghua University for reporting this issue.
This is CVE-2025-47912 and Go issue https://go.dev/issue/75678.
- encoding/asn1: pre-allocating memory when parsing DER payload can cause memory exhaustion
When parsing DER payloads, memories were being allocated prior to fully validating the payloads.
This permits an attacker to craft a big empty DER payload to cause memory exhaustion in functions such as asn1.Unmarshal, x509.ParseCertificateRequest, and ocsp.ParseResponse.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58185 and Go issue https://go.dev/issue/75671.
- net/http: lack of limit when parsing cookies can cause memory exhaustion
Despite HTTP headers having a default limit of 1 MB, the number of cookies that can be parsed did not have a limit.
By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.
net/http now limits the number of cookies accepted to 3000, which can be adjusted using the httpcookiemaxnum GODEBUG option.
Thanks to jub0bs for reporting this issue.
This is CVE-2025-58186 and Go issue https://go.dev/issue/75672.
- crypto/x509: panic when validating certificates with DSA public keys
Validating certificate chains which contain DSA public keys can cause programs
to panic, due to a interface cast that assumes they implement the Equal method.
This affects programs which validate arbitrary certificate chains.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58188 and Go issue https://go.dev/issue/75675.
- archive/tar: unbounded allocation when parsing GNU sparse map
tar.Reader did not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions could cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input could result in large allocations.
Thanks to Harshit Gupta (Mr HAX) - https://www.linkedin.com/in/iam-harshit-gupta/ for reporting this issue.
This is CVE-2025-58183 and Go issue https://go.dev/issue/75677.
- net/textproto: excessive CPU consumption in Reader.ReadResponse
The Reader.ReadResponse function constructed a response string through
repeated string concatenation of lines. When the number of lines in a response is large,
this could cause excessive CPU consumption.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61724 and Go issue https://go.dev/issue/75716.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This includes 1 security fix:
- net/http: CrossOriginProtection bypass patterns are over-broad
When passing patterns to CrossOriginProtection.AddInsecureBypassPattern,
requests that would have redirected to those patterns (e.g. without a trailing
slash) were also exempted, which might be unexpected.
Thanks to Marco Gazerro for reporting this issue.
This is CVE-2025-47910 and Go issue https://go.dev/issue/75054.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.7
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.4...go1.24.5
This minor releases include 1 security fixes following the security policy:
- cmd/go: unexpected command execution in untrusted VCS repositories
Various uses of the Go toolchain in untrusted VCS repositories can result in
unexpected code execution. When using the Go toolchain in directories fetched
using various VCS tools (such as directly cloning Git or Mercurial repositories)
can cause the toolchain to execute unexpected commands, if said directory
contains multiple VCS configuration metadata (such as a '.hg' directory in a Git
repository). This is due to how the Go toolchain attempts to resolve which VCS
is being used in order to embed build information in binaries and determine
module versions.
The toolchain will now abort attempting to resolve which VCS is being used if it
detects multiple VCS configuration metadata in a module directory or nested VCS
configuration metadata (such as a '.git' directoy in a parent directory and a
'.hg' directory in a child directory). This will not prevent the toolchain from
building modules, but will result in binaries omitting VCS related build
information.
If this behavior is expected by the user, the old behavior can be re-enabled by
setting GODEBUG=allowmultiplevcs=1. This should only be done in trusted
repositories.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting
this issue.
This is CVE-2025-4674 and https://go.dev/issue/74380.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.3...go1.24.4
This release includes 3 security fixes following the security policy:
- net/http: sensitive headers not cleared on cross-origin redirect
Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue.
This is CVE-2025-4673 and Go issue https://go.dev/issue/73816.
- os: inconsistent handling of O_CREATE|O_EXCL on Unix and Windows
os.OpenFile(path, os.O_CREATE|O_EXCL) behaved differently on Unix and Windows systems when the target path was a dangling symlink. On Unix systems, OpenFile with O_CREATE and O_EXCL flags never follows symlinks. On Windows, when the target path was a symlink to a nonexistent location, OpenFile would create a file in that location.
OpenFile now always returns an error when the O_CREATE and O_EXCL flags are both set and the target path is a symlink.
Thanks to Junyoung Park and Dong-uk Kim of KAIST Hacking Lab for discovering this issue.
This is CVE-2025-0913 and Go issue https://go.dev/issue/73702.
- crypto/x509: usage of ExtKeyUsageAny disables policy validation
Calling Verify with a VerifyOptions.KeyUsages that contains ExtKeyUsageAny unintentionally disabledpolicy validation. This only affected certificate chains which contain policy graphs, which are rather uncommon.
Thanks to Krzysztof Skrzętnicki (@Tener) of Teleport for reporting this issue.
This is CVE-2025-22874 and Go issue https://go.dev/issue/73612.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
full diff: https://github.com/golang/go/compare/go1.23.7...go1.23.8
release notes: https://go.dev/doc/devel/release#go1.24.2
go1.23.8 (released 2025-04-01) includes security fixes to the net/http package,
as well as bug fixes to the runtime and the go command. See the Go 1.23.8
milestone on our issue tracker for details;
https://github.com/golang/go/issues?q=milestone%3AGo1.23.8+label%3ACherryPickApproved
From the mailing list:
Hello gophers,
We have just released Go versions 1.24.2 and 1.23.8, minor point releases.
These minor releases include 1 security fixes following the security policy:
- net/http: request smuggling through invalid chunked data
The net/http package accepted data in the chunked transfer encoding
containing an invalid chunk-size line terminated by a bare LF.
When used in conjunction with a server or proxy which incorrectly
interprets a bare LF in a chunk extension as part of the extension,
this could permit request smuggling.
The net/http package now rejects chunk-size lines containing a bare LF.
Thanks to Jeppe Bonde Weikop for reporting this issue.
This is CVE-2025-22871 and Go issue https://go.dev/issue/71988.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This minor release include 1 security fix following the security policy:
- crypto/elliptic: timing sidechannel for P-256 on ppc64le
Due to the usage of a variable time instruction in the assembly implementation
of an internal function, a small number of bits of secret scalars are leaked on
the ppc64le architecture. Due to the way this function is used, we do not
believe this leakage is enough to allow recovery of the private key when P-256
is used in any well known protocols.
This is CVE-2025-22866 and Go issue https://go.dev/issue/71383.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.23.6
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.23.5 (released 2025-01-16) includes security fixes to the crypto/x509 and
net/http packages, as well as bug fixes to the compiler, the runtime, and the
net package. See the Go 1.23.5 milestone on our issue tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.23.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.23.4...go1.23.5
Hello gophers,
We have just released Go versions 1.23.5 and 1.22.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- crypto/x509: usage of IPv6 zone IDs can bypass URI name constraints
A certificate with a URI which has a IPv6 address with a zone ID may
incorrectly satisfy a URI name constraint that applies to the certificate
chain.
Certificates containing URIs are not permitted in the web PKI, so this
only affects users of private PKIs which make use of URIs.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2024-45341 and Go issue https://go.dev/issue/71156.
- net/http: sensitive headers incorrectly sent after cross-domain redirect
The HTTP client drops sensitive headers after following a cross-domain redirect.
For example, a request to a.com/ containing an Authorization header which is
redirected to b.com/ will not send that header to b.com.
In the event that the client received a subsequent same-domain redirect, however,
the sensitive headers would be restored. For example, a chain of redirects from
a.com/, to b.com/1, and finally to b.com/2 would incorrectly send the Authorization
header to b.com/2.
Thanks to Kyle Seely for reporting this issue.
This is CVE-2024-45336 and Go issue https://go.dev/issue/70530.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.22.7+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.22.6...go1.22.7
These minor releases include 3 security fixes following the security policy:
- go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.
This is CVE-2024-34155 and Go issue https://go.dev/issue/69138.
- encoding/gob: stack exhaustion in Decoder.Decode
Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion.
This is a follow-up to CVE-2022-30635.
Thanks to Md Sakib Anwar of The Ohio State University (anwar.40@osu.edu) for reporting this issue.
This is CVE-2024-34156 and Go issue https://go.dev/issue/69139.
- go/build/constraint: stack exhaustion in Parse
Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion.
This is CVE-2024-34158 and Go issue https://go.dev/issue/69141.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.23.1
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.12+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.11...go1.21.12
These minor releases include 1 security fixes following the security policy:
net/http: denial of service due to improper 100-continue handling
The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail.
An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.
Thanks to Geoff Franks for reporting this issue.
This is CVE-2024-24791 and Go issue https://go.dev/issue/67555.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.21.12
**- Description for the changelog**
```markdown changelog
Update Go runtime to 1.21.12
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.21.11 (released 2024-06-04) includes security fixes to the archive/zip
and net/netip packages, as well as bug fixes to the compiler, the go command,
the runtime, and the os package. See the Go 1.21.11 milestone on our issue
tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.11+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.10...go1.21.11
From the security announcement;
We have just released Go versions 1.22.4 and 1.21.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- archive/zip: mishandling of corrupt central directory record
The archive/zip package's handling of certain types of invalid zip files
differed from the behavior of most zip implementations. This misalignment
could be exploited to create an zip file with contents that vary depending
on the implementation reading the file. The archive/zip package now rejects
files containing these errors.
Thanks to Yufan You for reporting this issue.
This is CVE-2024-24789 and Go issue https://go.dev/issue/66869.
- net/netip: unexpected behavior from Is methods for IPv4-mapped IPv6 addresses
The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected
for IPv4-mapped IPv6 addresses, returning false for addresses which would
return true in their traditional IPv4 forms.
Thanks to Enze Wang of Alioth and Jianjun Chen of Zhongguancun Lab
for reporting this issue.
This is CVE-2024-24790 and Go issue https://go.dev/issue/67680.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.10+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.9...go1.21.10
These minor releases include 2 security fixes following the security policy:
- cmd/go: arbitrary code execution during build on darwin
On Darwin, building a Go module which contains CGO can trigger arbitrary code execution when using the Apple version of ld, due to usage of the -lto_library flag in a "#cgo LDFLAGS" directive.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2024-24787 and Go issue https://go.dev/issue/67119.
- net: malformed DNS message can cause infinite loop
A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop.
Thanks to long-name-let-people-remember-you on GitHub for reporting this issue, and to Mateusz Poliwczak for bringing the issue to our attention.
This is CVE-2024-24788 and Go issue https://go.dev/issue/66754.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.3
**- Description for the changelog**
```markdown changelog
Update Go runtime to 1.21.10
```
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.21.9 (released 2024-04-03) includes a security fix to the net/http
package, as well as bug fixes to the linker, and the go/types and
net/http packages. See the [Go 1.21.9 milestone](https://github.com/golang/go/issues?q=milestone%3AGo1.21.9+label%3ACherryPickApproved)
for more details.
These minor releases include 1 security fixes following the security policy:
- http2: close connections when receiving too many headers
Maintaining HPACK state requires that we parse and process all HEADERS
and CONTINUATION frames on a connection. When a request's headers exceed
MaxHeaderBytes, we don't allocate memory to store the excess headers but
we do parse them. This permits an attacker to cause an HTTP/2 endpoint
to read arbitrary amounts of header data, all associated with a request
which is going to be rejected. These headers can include Huffman-encoded
data which is significantly more expensive for the receiver to decode
than for an attacker to send.
Set a limit on the amount of excess header frames we will process before
closing a connection.
Thanks to Bartek Nowotarski (https://nowotarski.info/) for reporting this issue.
This is CVE-2023-45288 and Go issue https://go.dev/issue/65051.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.2
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.9+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.8...go1.21.9
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.21.5 (released 2023-12-05) includes security fixes to the go command,
and the net/http and path/filepath packages, as well as bug fixes to the
compiler, the go command, the runtime, and the crypto/rand, net, os, and
syscall packages. See the Go 1.21.5 milestone on our issue tracker for
details:
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.4...go1.21.5
from the security mailing:
[security] Go 1.21.5 and Go 1.20.12 are released
Hello gophers,
We have just released Go versions 1.21.5 and 1.20.12, minor point releases.
These minor releases include 3 security fixes following the security policy:
- net/http: limit chunked data overhead
A malicious HTTP sender can use chunk extensions to cause a receiver
reading from a request or response body to read many more bytes from
the network than are in the body.
A malicious HTTP client can further exploit this to cause a server to
automatically read a large amount of data (up to about 1GiB) when a
handler fails to read the entire body of a request.
Chunk extensions are a little-used HTTP feature which permit including
additional metadata in a request or response body sent using the chunked
encoding. The net/http chunked encoding reader discards this metadata.
A sender can exploit this by inserting a large metadata segment with
each byte transferred. The chunk reader now produces an error if the
ratio of real body to encoded bytes grows too small.
Thanks to Bartek Nowotarski for reporting this issue.
This is CVE-2023-39326 and Go issue https://go.dev/issue/64433.
- cmd/go: go get may unexpectedly fallback to insecure git
Using go get to fetch a module with the ".git" suffix may unexpectedly
fallback to the insecure "git://" protocol if the module is unavailable
via the secure "https://" and "git+ssh://" protocols, even if GOINSECURE
is not set for said module. This only affects users who are not using
the module proxy and are fetching modules directly (i.e. GOPROXY=off).
Thanks to David Leadbeater for reporting this issue.
This is CVE-2023-45285 and Go issue https://go.dev/issue/63845.
- path/filepath: retain trailing \ when cleaning paths like \\?\c:\
Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the
volume name in Windows paths starting with \\?\, resulting in
filepath.Clean(\\?\c:\) returning \\?\c: rather than \\?\c:\ (among
other effects). The previous behavior has been restored.
This is an update to CVE-2023-45283 and Go issue https://go.dev/issue/64028.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.4 (released 2023-11-07) includes security fixes to the path/filepath
package, as well as bug fixes to the linker, the runtime, the compiler, and
the go/types, net/http, and runtime/cgo packages. See the Go 1.21.4 milestone
on our issue tracker for details:
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.3...go1.21.4
from the security mailing:
[security] Go 1.21.4 and Go 1.20.11 are released
Hello gophers,
We have just released Go versions 1.21.4 and 1.20.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- path/filepath: recognize `\??\` as a Root Local Device path prefix.
On Windows, a path beginning with `\??\` is a Root Local Device path equivalent
to a path beginning with `\\?\`. Paths with a `\??\` prefix may be used to
access arbitrary locations on the system. For example, the path `\??\c:\x`
is equivalent to the more common path c:\x.
The filepath package did not recognize paths with a `\??\` prefix as special.
Clean could convert a rooted path such as `\a\..\??\b` into
the root local device path `\??\b`. It will now convert this
path into `.\??\b`.
`IsAbs` did not report paths beginning with `\??\` as absolute.
It now does so.
VolumeName now reports the `\??\` prefix as a volume name.
`Join(`\`, `??`, `b`)` could convert a seemingly innocent
sequence of path elements into the root local device path
`\??\b`. It will now convert this to `\.\??\b`.
This is CVE-2023-45283 and https://go.dev/issue/63713.
- path/filepath: recognize device names with trailing spaces and superscripts
The `IsLocal` function did not correctly detect reserved names in some cases:
- reserved names followed by spaces, such as "COM1 ".
- "COM" or "LPT" followed by a superscript 1, 2, or 3.
`IsLocal` now correctly reports these names as non-local.
This is CVE-2023-45284 and https://go.dev/issue/63713.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.3 (released 2023-10-10) includes a security fix to the net/http package.
See the Go 1.21.3 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.21.3+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.21.2...go1.21.3
From the security mailing:
[security] Go 1.21.3 and Go 1.20.10 are released
Hello gophers,
We have just released Go versions 1.21.3 and 1.20.10, minor point releases.
These minor releases include 1 security fixes following the security policy:
- net/http: rapid stream resets can cause excessive work
A malicious HTTP/2 client which rapidly creates requests and
immediately resets them can cause excessive server resource consumption.
While the total number of requests is bounded to the
http2.Server.MaxConcurrentStreams setting, resetting an in-progress
request allows the attacker to create a new request while the existing
one is still executing.
HTTP/2 servers now bound the number of simultaneously executing
handler goroutines to the stream concurrency limit. New requests
arriving when at the limit (which can only happen after the client
has reset an existing, in-flight request) will be queued until a
handler exits. If the request queue grows too large, the server
will terminate the connection.
This issue is also fixed in golang.org/x/net/http2 v0.17.0,
for users manually configuring HTTP/2.
The default stream concurrency limit is 250 streams (requests)
per HTTP/2 connection. This value may be adjusted using the
golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams
setting and the ConfigureServer function.
This is CVE-2023-39325 and Go issue https://go.dev/issue/63417.
This is also tracked by CVE-2023-44487.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.2 (released 2023-10-05) includes one security fixes to the cmd/go package,
as well as bug fixes to the compiler, the go command, the linker, the runtime,
and the runtime/metrics package. See the Go 1.21.2 milestone on our issue
tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.21.2+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.21.1...go1.21.2
From the security mailing:
[security] Go 1.21.2 and Go 1.20.9 are released
Hello gophers,
We have just released Go versions 1.21.2 and 1.20.9, minor point releases.
These minor releases include 1 security fixes following the security policy:
- cmd/go: line directives allows arbitrary execution during build
"//line" directives can be used to bypass the restrictions on "//go:cgo_"
directives, allowing blocked linker and compiler flags to be passed during
compliation. This can result in unexpected execution of arbitrary code when
running "go build". The line directive requires the absolute path of the file in
which the directive lives, which makes exploting this issue significantly more
complex.
This is CVE-2023-39323 and Go issue https://go.dev/issue/63211.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
