A discrepancy between how Go and C/C++ comments were parsed allowed for code smuggling into the resulting cgo binary.

It was possible to improperly access the parent directory of an os.Root by opening a filename ending in "../". For example, Root.Open("../") would open the parent directory of the Root. This escape only permits opening the parent directory itself, not ancestors of the parent or files contained within the parent.

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.

https://groups.google.com/g/golang-announce/c/EdhZqrQ98hk announces: 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.

View the release notes for more information: https://go.dev/doc/devel/release#go1.26.1

You 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.26.1 and build as usual.

Thanks to everyone who contributed to the releases.

Cheers, Cherry and David for the Go team

https://groups.google.com/g/golang-announce/c/K09ubi9FQFk announces: 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.7

You 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.

Cheers, Michael and Dmitri for the Go team

Hi,

I am the original reporter of the vulnerabilities recently addressed in Go 1.25.6/1.24.x (CVE-2025-61730, CVE-2025-68121).

I am writing to inform the community that the official fix provided by the Go security team is critically flawed and causes significant regressions in the networking ecosystem (notably breaking quic-go).

1. Missing Root Cause in Official Advisory

The official advisory attributes the risk to "misuse of APIs," but the root cause is a fundamental logic error in Go's TLS 1.3 state machine during session resumption.

Specifically, it fails to re-validate the identity of the trust anchor when a session is resumed, allowing for Cross-CA certificate bypass.

2. Flawed Patch Implementation

The current official patch (CL 735051) contains amateurish errors that undermine its effectiveness:

Incorrect Indexing: It attempts to verify peerCertificates instead of the verifiedChain (that include RootCA).

Ecosystem Breakage: By aggressively blocking Config.Clone logic to "fix" the issue, it has paralyzed 0-RTT and session resumption in the QUIC ecosystem.

3. Proposed O(1) Solution

I have proposed a far more elegant solution that performs a constant-time SHA-224 fingerprint check of the root CA.

This fixes the vulnerability without breaking the Config.Clone semantics or performance.

Details and Discussion:

https://github.com/golang/go/issues/77217

I encourage downstream maintainers (SUSE, Red Hat, Debian) to review the fix before deploying it to mission-critical infrastructure.

Best regards, Coia Prant (rbqvq)

https://groups.google.com/g/golang-announce/c/Vd2tYVM8eUc announces: 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:

- 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

You 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, The Go team

https://groups.google.com/g/golang-announce/c/8FJoBkPddm4 announces: Hello gophers,

We have just released Go versions 1.25.5 and 1.24.11, minor point releases.

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

You 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.5 and build as usual.

Thanks to everyone who contributed to the releases.

Cheers, Dmitri and Cherry for the Go team -- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris