- February 2026
- No date parsed from source.
- First seen by Releasebot:Feb 10, 2026
Go 1.26.0 is released
Hello gophers,
We have just released Go 1.26.0.
To find out what has changed in Go 1.26, read the release notes:
https://go.dev/doc/go1.26You can download binary and source distributions from our download page:
https://go.dev/dl/#go1.26.0If you have Go installed already, an easy way to try go1.26.0
is by using the go command:$ go install golang.org/dl/go1.26.0@latest $ go1.26.0 downloadTo compile from source using a Git clone, update to the release with
git checkout go1.26.0and build as usual.
Thanks to everyone who contributed to the release!
Cheers,
Original source Report a problem
Junyang and Michael for the Go team - Feb 10, 2026
- Date parsed from source:Feb 10, 2026
- First seen by Releasebot:Feb 10, 2026
Go 1.26 is released
Go 1.26 ships with language refinements, performance boosts, and improved tooling. It adds an expression form for new, enables the Green Tea GC by default, and brings several compiler and library improvements along with experimental features to try.
Language changes
Go 1.26 introduces two significant refinements to the language syntax and type system.
First, the built-in new function, which creates a new variable, now allows its operand to be an expression, specifying the initial value of the variable.
A simple example of this change means that code such as this:
x := int64(300)
ptr := &x
Can be simplified to:ptr := new(int64(300))Second, generic types may now refer to themselves in their own type parameter list. This change simplifies the implementation of complex data structures and interfaces.
Performance improvements
The previously experimental Green Tea garbage collector is now enabled by default.
The baseline cgo overhead has been reduced by approximately 30%.
The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance.
Tool improvements
The go fix command has been completely rewritten to use the Go analysis framework, and now includes a couple dozen “modernizers”, analyzers that suggest safe fixes to help your code take advantage of newer features of the language and standard library. It also includes the inline analyzer, which attempts to inline all calls to each function annotated with a //go:fix inline directive. Two upcoming blog posts will address these features in more detail.
More improvements and changes
Go 1.26 introduces many improvements over Go 1.25 across its tools, the runtime, compiler, linker, and the standard library. This includes the addition of three new packages: crypto/hpke, crypto/mlkem/mlkemtest, and testing/cryptotest. There are port-specific changes and GODEBUG settings updates.
Some of the additions in Go 1.26 are in an experimental stage and become exposed only when you explicitly opt in. Notably:
- An experimental simd/archsimd package provides access to “single instruction, multiple data” (SIMD) operations.
- An experimental runtime/secret package provides a facility for securely erasing temporaries used in code that manipulates secret information, typically cryptographic in nature.
- An experimental goroutineleak profile in the runtime/pprof package that reports leaked goroutines.
These experiments are all expected to be generally available in a future version of Go. We encourage you to try them out ahead of time. We really value your feedback!
Please refer to the Go 1.26 Release Notes for the complete list of additions, changes, and improvements in Go 1.26.
Over the next few weeks, follow-up blog posts will cover some of the topics relevant to Go 1.26 in more detail. Check back later to read those posts.
Thanks to everyone who contributed to this release by writing code, filing bugs, trying out experimental additions, sharing feedback, and testing the release candidates. Your efforts helped make Go 1.26 as stable as possible. As always, if you notice any problems, please file an issue.
We hope you enjoy using the new release!
Original source Report a problem All of your release notes in one place
Join Releasebot and get updates from Google and hundreds of other software products.
- February 2026
- No date parsed from source.
- First seen by Releasebot:Feb 5, 2026
[security] Go 1.26 Release Candidate 3 is released
Go 1.26 RC3 is out with a TLS session resumption fix and notes on Config.GetConfigForClient. This release invites load testing and telemetry opt-in to validate the pre-release build and tighten security.
Go 1.26rc3 Release Notes
Hello gophers,
We have just released go1.26rc3, a release candidate version of Go 1.26.
It is cut from release-branch.go1.26 at the revision tagged go1.26rc3.
This release includes 1 security fix following the security policy:- 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 .
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Report any problems using the issue tracker:
https://go.dev/issue/new
Please consider opting in to Go telemetry if you haven't already.
Go telemetry helps validate this release candidate and future Go releases.
You can opt in by running the following command:
$ go telemetry on
If you have Go installed already, an easy way to try go1.26rc3 is by using the go command:
$ go install
golang.org/dl/go1.26rc3@latest
$ go1.26rc3 download
You can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.26rc3
To find out what has changed in Go 1.26, read the draft release notes:
https://tip.golang.org/doc/go1.26
Cheers,
Michael and Dmitri for the Go team
Telemetry and testing commands
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.You can opt in by running the following command:
$ go telemetry onIf you have Go installed already, an easy way to try go1.26rc3 is by using the go command:
$ go install golang.org/dl/go1.26rc3@latest $ go1.26rc3 downloadYou can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.26rc3To find out what has changed in Go 1.26, read the draft release notes:
https://tip.golang.org/doc/go1.26Cheers,
Original source Report a problem
Michael and Dmitri for the Go team - Feb 4, 2026
- Date parsed from source:Feb 4, 2026
- First seen by Releasebot:Feb 5, 2026
[security] Go 1.25.7 and Go 1.24.13 are released
Go releases 1.25.7 and 1.24.13 bring critical security fixes with safety improvements in cgo and TLS. They fix code smuggling in cgo doc strings and tighten session-resumption checks in crypto/tls to honor configured auth.
Go 1.25.7 and 1.24.13 Release Notes
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.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.7You can download binary and source distributions from the Go website:
https://go.dev/dl/To compile from source using a Git clone, update to the release with
git checkout go1.25.7
and build as usual.Thanks to everyone who contributed to the releases.
Original source Report a problem
Cheers,
Michael and Dmitri for the Go team - January 2026
- No date parsed from source.
- First seen by Releasebot:Jan 16, 2026
Go 1.26 Release Candidate 2
Go 1.26 RC2 is released with six security fixes and TLS/session handling improvements, plus safer toolchain VCS behavior. It’s a clear release upgrade you should test in production load and unit tests. Get it via go1.26rc2 download and test now.
Go 1.26 Release Candidate go1.26rc2
Hello gophers,
We have just released go1.26rc2, a release candidate version of Go 1.26.
It is cut from release-branch.go1.26 at the revision tagged go1.26rc2.
This release 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
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Report any problems using the issue tracker:
https://go.dev/issue/new
If you have Go installed already, an easy way to try go1.26rc2
is by using the go command:$ go install golang.org/dl/go1.26rc2@latest $ go1.26rc2 downloadYou can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.26rc2
To find out what has changed in Go 1.26, read the draft release notes:
https://tip.golang.org/doc/go1.26Cheers,
Original source Report a problem
Junyang and Michael for the Go team - Jan 15, 2026
- Date parsed from source:Jan 15, 2026
- First seen by Releasebot:Feb 5, 2026
[release-branch.go1.26] go1.26rc2
Change details
- Change-Id: If5ce85a68010848f16c4c2509e18466ed1356912
- Reviewed-on: https://go-review.googlesource.com/c/go/+/736763
- TryBot-Bypass: Gopher Robot [email protected]
- Reviewed-by: Michael Pratt [email protected]
- Reviewed-by: Junyang Shao [email protected]
- Auto-Submit: Gopher Robot [email protected]
- Jan 15, 2026
- Date parsed from source:Jan 15, 2026
- First seen by Releasebot:Jan 16, 2026
[security] Go 1.25.6 and Go 1.24.12 are released
Go releases 1.25.6 and 1.24.12 fix six security flaws across archive/zip, net/http, crypto/tls, and the Go toolchain, addressing DoS, memory exhaustion, and code execution risks. Upgrading is recommended to stay protected and secure.
Hello gophers,
We have just released Go versions 1.25.6 and 1.24.12, minor point releases.
These releases include 6 security fixes following the security policy :
Security fixes
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.6You can download binary and source distributions from the Go website:
https://go.dev/dl/To compile from source using a Git clone, update to the release with
git checkout go1.25.6
and build as usual.Thanks to everyone who contributed to the releases.
Cheers,
Original source Report a problem
The Go team - Dec 18, 2025
- Date parsed from source:Dec 18, 2025
- First seen by Releasebot:Jan 14, 2026
[security] Vulnerability in Visual Studio Code Go extension
Go Security Team releases vscode-go updates to fix a Restricted Mode risk. The extension now disables itself in Restricted Mode to prevent untrusted code execution (CVE-2025-68120). VS Code will auto update; manual update guidance is provided.
Release notes
Hello gophers,
We have released versions v0.52.1 (regular) and v0.53.0 (pre-release) of the Visual Studio Code vscode-go extension (also known as vscode-go) in order to address a security issue.
This release fixes unexpected behavior when operating in Restricted Mode. To prevent accidental untrusted code execution, the extension is now disabled in Restricted Mode.
This is CVE-2025-68120.
Visual Code Studio should automatically update the extension to the new version, if it is installed. To manually update the extension see https://code.visualstudio.com/docs/configure/extensions/extension-marketplace#_update-an-extension-manually.
Cheers,
Original source Report a problem
Go Security Team - Dec 16, 2025
- Date parsed from source:Dec 16, 2025
- First seen by Releasebot:Jan 14, 2026
Go 1.26 Release Candidate 1 is released
Go 1.26rc1 is released as a release candidate. Developers are urged to test in production, report issues, and opt into telemetry. Download binaries or try via go1.26rc1 and read the draft release notes for Go 1.26.
Go 1.26rc1 Release Candidate
Hello gophers,
We have just released go1.26rc1, a release candidate version of Go 1.26.
It is cut from release-branch.go1.26 at the revision tagged go1.26rc1.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Report any problems using the issue tracker:
https://go.dev/issue/newPlease consider opting in to
Go telemetry
if you haven't already.
Go telemetry helps validate this release candidate and future Go releases.
You can opt in by running the following command:$ go telemetry onIf you have Go installed already, an easy way to try go1.26rc1
is by using the go command:$ go install golang.org/dl/go1.26rc1@latest$ go1.26rc1 downloadYou can download binary and source distributions from the usual place:
https://go.dev/dl/#go1.26rc1To find out what has changed in Go 1.26, read the draft release notes:
https://tip.golang.org/doc/go1.26Cheers,
Original source Report a problem
Michael and David for the Go team - Dec 2, 2025
- Date parsed from source:Dec 2, 2025
- First seen by Releasebot:Feb 11, 2026
[security] Go 1.25.5 and Go 1.24.11 pre-announcement
Hello gophers,
We plan to issue Go 1.25.5 and Go 1.24.11 during US business hours on Tuesday, December 2.
These minor releases include PRIVATE security fixes to the standard library, covering the following CVE:
- CVE-2025-61729
Following our security policy, this is the pre-announcement of those releases.
Thanks,
Original source Report a problem
The Go team