The go command may execute unexpected commands when operating in untrusted VCS repositories. This occurs when possibly dangerous VCS configuration is present in repositories. This can happen when a repository was fetched via one VCS (e.g. Git), but contains metadata for another VCS (e.g. Mercurial). Modules which are retrieved using the go command line, i.e. via "go get", are not affected.

Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error.

If the PATH environment variable contains paths which are executables (rather than just directories), passing certain strings to LookPath ("", ".", and ".."), can result in the binaries listed in the PATH being unexpectedly returned.

Arbitrary code execution during build on Darwin in cmd/go

Despite HTTP headers having a default limit of 1MB, the number of cookies that can be parsed does 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.

SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.

The compiler is meant to unwrap pointers which are the operands of a memory move; a no-op interface conversion prevented the compiler from making the correct determination about non-overlapping moves, potentially leading to memory corruption at runtime.

End of life: 2/10/2026, Latest version: 1.24.13

End of life: 8/19/2026, Latest version: 1.25.14

Latest version: 1.26.8

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

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

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

Thanks to everyone who contributed to the releases.

Cheers, David and Junyang for the Go team

On Wed, Apr 08, 2026 at 04:24:34PM -0700, Alan Coopersmith wrote: https://groups.google.com/g/golang-announce/c/0uYbvbPZRWU announces: 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: This includes 2 issues in the compiler itself, which made some Go programs not memory safe: 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. Jakub Ciolek who found these 2 issues (and had inadvertently introduced "the underlying issue behind the first bug [...] more than three years earlier") posted an excellent write-up about them here:

https://ciolek.dev/posts/when-the-compiler-lies

Here's my quick attempt at a plain text conversion: When the compiler lies: breaking memory safety in safe Go 0001 go / memory safety / compilers

Early in March, I reported two compiler bugs affecting Go releases up to 1.26.1 which broke the Go memory safety guarantees using only safe Go code.

This means the proof-of-concepts did not import unsafe, did not use CGO and did not rely on custom assembly nor data races. Using specially constructed code, I was able to turn both bugs into control-flow hijack, and with the loop bug I also got execution of injected instructions.

I’m not including the full end-to-end exploits, to allow the fixed releases to become more widely available. I’ll briefly describe the issues and show the problematic code patterns though. An interesting learning from this, perhaps obvious to some people, is that memory safety is a property of the whole toolchain, not only the language itself.

I found the bugs after I decided to have a closer look at the compiler. I had reported several denial-of-service issues in the standard library before. I have spent a few years contributing smaller patches to the compiler on-and-off so it was a codebase I understood reasonably well. In late November I found two errors in the devel version of the prove optimization pass (the step that infers limits and “proves” facts about SSA values, among others to perform bounds check elimination).

If you exclude the generated rewrite tables, prove is basically the second largest backend SSA optimization pass, behind only the register allocator itself. It also deals with arithmetic and signedness, two easy ways to shoot yourself in the foot. It turned out, the hunch was correct as there were more problems lurking in that area. This time in the release versions of Go.

BUG 1: A LOOP THAT WRAPPED AND THE COMPILER SWORE IT DIDN’T

CVE-2026-27143

The first problem existed in the prove/loopbce reasoning about induction variables and bound checks.

The triggering shape is surprisingly simple:

for i := int8(0); i <= int8(120); i += int8(10) { arr[i] = value }

Question to you: if i == 120 and you perform the iteration, then add 10 to it, what will you get? What’s the answer? 130? It turns out the answer is -126. int8 has eight bits, it wraps.

That’s literally the whole bug. The compiler believed something different though.

If you make prove emit debug data, these are the facts it inferred:

Induction variable: limits [0,120], increment 10 Proved IsInBounds

Once it takes those facts, it will confidently remove bound checking for array access if the array size fits within the induction variable limits. In this case, the index can become negative. With correct arrangement of surrounding code, we can make the program jump to an arbitrary address, change control flow or even inject instructions.

I must admit I could not believe this at first and reran the program many times on different machines and different versions of the compiler. Vulnerability hunting gives a large thrill when you finally confirm something is a real security bug. When I found it, I was really ecstatic, as bad as it sounds. That feeling would change soon, but more about that later.

BUG 2: A NO-OP CONVERSION THAT CHANGED NOTHING AND BROKE EVERYTHING

CVE-2026-27144

The second problem lived in another place, slightly later, in the SSA lowering phase. The compiler knows to be careful when copying from one part of an array into an overlapping nearby part. This is important for safety. It turns out, if you wrapped the source into a conversion that didn’t really change anything, the compiler forgot to do that.

type T [N][]uint64

// buggy shape p = T(q)

// control shape p = q

Those two lines should mean the same thing here. The conversion does not really matter, the overlap does. p and q can point at partially overlapping windows of the same underlying array. Once that is true, the compiler should use the careful copy path. If it does not do that, it can overwrite data it has not read yet. If you do that over simple data, you get a wrong result. If you do that over more complex composite values it gets more interesting. If you do that to slice values, later code still trusts the result. A harmless-looking assignment then turns into memory corruption.

TWO DISTINCT PROBLEMS, BUT REALLY THE SAME CAUSE

Those two bugs resided in two different parts of the compiler, but the root cause was the same. In the first case, the compiler erased the possibility of signed wrap. In the second one, it excluded the possibility of overlap.

Those were two different mechanisms of failure, but both caused by the same problem: counterfeit certainty. I guess that’s how compilers break, you can write some compiler code and it looks reasonable, there’s math and tests and everything seems correct. Things get reviewed by multiple people and merged, but it turns out you may accidentally upgrade “probably safe” into “proved safe” way too soon.

Then, once the compiler starts to generate and optimize code based on that promise, it will miscompile. Sometimes, like in those cases, you can make the code dance around it and break security boundaries.

THEN GIT BLAME GOT PERSONAL

As I was wrapping up the email to the Go security team, I sat down to write the last part of the advisory. I was still ecstatic about the find. The final part was to figure out when this was introduced. I did the routine thing and ran git blame.

It came back with my own name. That was not ideal and I did not like it. I got a sinking feeling in my stomach and went from feeling really smart to feeling really dumb, real fast.

It turns out that the underlying issue behind the first bug came from a CL I landed more than three years earlier.

I got over it by the next day and now see it as an amusing story, but it was quite an experience.

DISCLOSURE

I reported both issues back in March.

I must commend the Go security team as they are always excellent. Neal got back to me within 3 minutes of the first report and within 4 minutes of the second report. Mind you, those were sent days apart. Typically, the Go security advisories take up to a week to get a response. I guess seeing “memory corruption” and “compiler bug” in the same email thread speeds the process up.

I’ll publish the full minimized reproducers, deeper technical dive and more once the fixed releases become more broadly available.

LEARNINGS

The main learning for myself is that a memory-safe language is only as safe as the entire toolchain enforcing its invariants. Frontend, optimizer, lowering, runtime and code generation. All of those parts sit within the trust boundary. If parts of it start certifying wrong proofs and generating code on top of that, the source code can stay safe while the compiled program stops being memory-safe.

Every optimization is a security claim and most of the time those claims are true. In this case, those two were not.

STATUS

Disclosure in progress

Full end-to-end exploits and minimized reproducers are intentionally omitted until the fixed releases are more widely available.

AFFECTED

Two compiler bugs affecting release versions of Go up to 1.26.1. Alexander

On Fri, Apr 10, 2026 at 04:58:03AM +0200, Solar Designer wrote: On Wed, Apr 08, 2026 at 04:24:34PM -0700, Alan Coopersmith wrote: https://groups.google.com/g/golang-announce/c/0uYbvbPZRWU announces: 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: This includes 2 issues in the compiler itself, which made some Go programs not memory safe: ...

I did not see any Linux distribution advisories for compiled Go programs yet, but some projects using Go have released upates:

- https://rclone.org/changelog/#v1-73-4-2026-04-08 Update to go 1.25.9 to fix multiple CVEs

- https://github.com/grafana/grafana/releases/tag/v12.4.3 2026-04-14: Go: Update to 1.25.9

I looked at https://github.com/gopasspw/gopass and https://github.com/restic/restic, but they have not yet issued updated releases.

Perhaps the message did not spread wide enough. Or are many Go programs just not affected?

Matthias

Eli Schwartz <eschwartz () gentoo org> writes: On 4/17/26 6:30 AM, Matthias Ferdinand wrote: On Fri, Apr 10, 2026 at 04:58:03AM +0200, Solar Designer wrote: On Wed, Apr 08, 2026 at 04:24:34PM -0700, Alan Coopersmith wrote: https://groups.google.com/g/golang-announce/c/0uYbvbPZRWU announces: 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: This includes 2 issues in the compiler itself, which made some Go programs not memory safe: ...

I did not see any Linux distribution advisories for compiled Go programs yet, but some projects using Go have released upates:

- https://rclone.org/changelog/#v1-73-4-2026-04-08 Update to go 1.25.9 to fix multiple CVEs

- https://github.com/grafana/grafana/releases/tag/v12.4.3 2026-04-14: Go: Update to 1.25.9

I looked at https://github.com/gopasspw/gopass and https://github.com/restic/restic, but they have not yet issued updated releases.

Perhaps the message did not spread wide enough. Or are many Go programs just not affected? Updated releases don't really make sense, generically. The bug is in the compiler, not the package, so one would rebuild the existing release with a new compiler. Consider how you handle this if a package had a security vulnerability in the GCC version it was compiled in. Or, it depended on libarchive and libarchive had a security release. Do you tag a brand new version of rclone because the dependencies it was compiled against got updated? No. Well, given gomodules or rust crate locking, maybe, because those are "vendored libraries", but that is a bug in both of those languages. :)

If I look at rclone, I see they only updated go 1.25.9 in the CI workflow that builds precompiled binaries and attaches them as github releases assets. The actual rclone release was noteworthy more for fixing a denial of service that required pulling in a newer version of a vendored library. For serious issues, it may make sense for projects distributing binaries (provided they know it was built by a buggy compiler) in the same way they might do for a vulnerable OpenSSL DLL in their Windows offering.

But yes, I agree, it'd be pretty annoying if every Go piece of software issued a new release that was a no-op and was just there to nudge you to rebuild it. On the compiler side of things, Gentoo Linux policy is to offer a standard approach to rebuilding all packages that use golang:

$ emerge @golang-rebuild

which should be run after all golang updates that one suspects deserve a global rebuild. Likely all golang updates because Reasons(tm). This is just the name of the game when installing golang software -- the usual rule of thumb is to assume all golang releases contain CVEs that need fixing. It is regular like clockwork, so do people really need an invitation to do so? Right, the stdlib case is pretty common. Other distros should be bumping the build number and recompiling the package in place, using the same infrastructure otherwise used for things like rebuilding ten thousand packages against a new major edition of perl or python or ruby.

IIRC it is possible to determine which packages actually need rebuilding for any given CVE, but to do so you need to locally extract the entire recursive deps-included source code of every package, and run some arcane undocumented go .... invocation. Functionally, what you're doing is checking which programs link to an internal static library distributed with the go compiler. (This is not exactly correct, but it is a useful mental model.) sam

On 4/17/26 6:30 AM, Matthias Ferdinand wrote: On Fri, Apr 10, 2026 at 04:58:03AM +0200, Solar Designer wrote: On Wed, Apr 08, 2026 at 04:24:34PM -0700, Alan Coopersmith wrote: https://groups.google.com/g/golang-announce/c/0uYbvbPZRWU announces: 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: This includes 2 issues in the compiler itself, which made some Go programs not memory safe: ...

I did not see any Linux distribution advisories for compiled Go programs yet, but some projects using Go have released upates:

- https://rclone.org/changelog/#v1-73-4-2026-04-08 Update to go 1.25.9 to fix multiple CVEs

- https://github.com/grafana/grafana/releases/tag/v12.4.3 2026-04-14: Go: Update to 1.25.9

I looked at https://github.com/gopasspw/gopass and https://github.com/restic/restic, but they have not yet issued updated releases.

Perhaps the message did not spread wide enough. Or are many Go programs just not affected? Updated releases don't really make sense, generically. The bug is in the compiler, not the package, so one would rebuild the existing release with a new compiler. Consider how you handle this if a package had a security vulnerability in the GCC version it was compiled in. Or, it depended on libarchive and libarchive had a security release. Do you tag a brand new version of rclone because the dependencies it was compiled against got updated? No. Well, given gomodules or rust crate locking, maybe, because those are "vendored libraries", but that is a bug in both of those languages. :)

If I look at rclone, I see they only updated go 1.25.9 in the CI workflow that builds precompiled binaries and attaches them as github releases assets. The actual rclone release was noteworthy more for fixing a denial of service that required pulling in a newer version of a vendored library.

On the compiler side of things, Gentoo Linux policy is to offer a standard approach to rebuilding all packages that use golang:

$ emerge @golang-rebuild

which should be run after all golang updates that one suspects deserve a global rebuild. Likely all golang updates because Reasons(tm). This is just the name of the game when installing golang software -- the usual rule of thumb is to assume all golang releases contain CVEs that need fixing. It is regular like clockwork, so do people really need an invitation to do so?

Other distros should be bumping the build number and recompiling the package in place, using the same infrastructure otherwise used for things like rebuilding ten thousand packages against a new major edition of perl or python or ruby.

IIRC it is possible to determine which packages actually need rebuilding for any given CVE, but to do so you need to locally extract the entire recursive deps-included source code of every package, and run some arcane undocumented go .... invocation. Functionally, what you're doing is checking which programs link to an internal static library distributed with the go compiler. (This is not exactly correct, but it is a useful mental model.)

-- Eli Schwartz

[ hopefully, discussing binary releases is not off-topic ]

On Sat, Apr 18, 2026 at 12:18:44AM +0100, Sam James wrote: Eli Schwartz <eschwartz () gentoo org> writes: On 4/17/26 6:30 AM, Matthias Ferdinand wrote: Perhaps the message did not spread wide enough. Or are many Go programs just not affected?

For serious issues, it may make sense for projects distributing binaries (provided they know it was built by a buggy compiler) in the same way they might do for a vulnerable OpenSSL DLL in their Windows offering.

$ emerge @golang-rebuild ... fixing. It is regular like clockwork, so do people really need an invitation to do so? Personally, I am guilty of not compiling packages myself (except for some pkgsrc) and using mostly distributions in binary package form (Debian, Ubuntu, Alma). Also, many projects on github release binary packages. Doing a fresh release with no change except for the compiler used (and some new release version or build number) may make sense for those projects with affected binaries. IIRC it is possible to determine which packages actually need rebuilding for any given CVE, but to do so you need to locally extract the entire recursive deps-included source code of every package, and run some arcane undocumented go .... invocation. Functionally, what you're doing is checking which programs link to an internal static library distributed with the go compiler. (This is not exactly correct, but it is a useful mental model.) Don't know enough Go to check affectedness of any project myself, but if it is that difficult it makes me worry even more :-) In the original advisory I did not see any mention if/how these issues propagate into compiled applications, and I only started worrying after reading the blog post about the memory safety issues and seeing that some projects had started issuing updates.

A vulnerability in the build chain of course takes more time to assess and solve for all binaries in a binary distribution. Or you could just issue package updates for all Go applications (as proposed by Eli Schwarz). Not sure if I would really to want to see either every project/package using Go listed under the existing CVEs, or a new CVE issued for each just for increased visibility. I just wondered why the impact on binaries and binary packages is not being discussed more broadly (anywhere, not just oss-security).

https://security-tracker.debian.org/tracker/CVE-2026-... only lists golang packages as affected, with some as already fixed and released, e.g. https://security-tracker.debian.org/tracker/CVE-2026-33810 (DNS contraints).

https://ubuntu.com/security/CVE-2026-... are still showing "Needs evaluation" for the golang packages, but they contain a comment by Marc Deslauriers: "Packages built using golang need to be rebuilt once the vulnerability has been fixed."

Alpine has bumped build numbers, as Chad Dougherty wrote here From: Chad Dougherty <crd477 () icloud com> Not an advisory, but Alpine did this: https://git.alpinelinux.org/aports/commit/?h=3.23-stable&id=f43ed43f4d329cb8cbca59b90c9560ab9e6d8f42 Alpine also had fresh releases on 2026-04-15, including some updates "rebuild with Go ..."

Arch linux appears not to have recompiled Go applications (or at least not all of them, only checked restic)

repo.almalinux.org does not show updated golang versions, so probably no recompiled Go applications either.

Matthias

Hi,

On Sun, Apr 19, 2026 at 10:14 PM Matthias Ferdinand <ml.oss-security () mfedv net> wrote: [ hopefully, discussing binary releases is not off-topic ]

On Sat, Apr 18, 2026 at 12:18:44AM +0100, Sam James wrote: Eli Schwartz <eschwartz () gentoo org> writes: On 4/17/26 6:30 AM, Matthias Ferdinand wrote: Perhaps the message did not spread wide enough. Or are many Go programs just not affected?

For serious issues, it may make sense for projects distributing binaries (provided they know it was built by a buggy compiler) in the same way they might do for a vulnerable OpenSSL DLL in their Windows offering.

$ emerge @golang-rebuild ... fixing. It is regular like clockwork, so do people really need an invitation to do so? Personally, I am guilty of not compiling packages myself (except for some pkgsrc) and using mostly distributions in binary package form (Debian, Ubuntu, Alma). Also, many projects on github release binary packages. Doing a fresh release with no change except for the compiler used (and some new release version or build number) may make sense for those projects with affected binaries. IIRC it is possible to determine which packages actually need rebuilding for any given CVE, but to do so you need to locally extract the entire recursive deps-included source code of every package, and run some arcane undocumented go .... invocation. Functionally, what you're doing is checking which programs link to an internal static library distributed with the go compiler. (This is not exactly correct, but it is a useful mental model.) Don't know enough Go to check affectedness of any project myself, but if it is that difficult it makes me worry even more :-) In the original advisory I did not see any mention if/how these issues propagate into compiled applications, and I only started worrying after reading the blog post about the memory safety issues and seeing that some projects had started issuing updates.

A vulnerability in the build chain of course takes more time to assess and solve for all binaries in a binary distribution. Or you could just issue package updates for all Go applications (as proposed by Eli Schwarz). Not sure if I would really to want to see either every project/package using Go listed under the existing CVEs, or a new CVE issued for each just for increased visibility. I just wondered why the impact on binaries and binary packages is not being discussed more broadly (anywhere, not just oss-security).

https://security-tracker.debian.org/tracker/CVE-2026-... only lists golang packages as affected, with some as already fixed and released, e.g. https://security-tracker.debian.org/tracker/CVE-2026-33810 (DNS contraints).

https://ubuntu.com/security/CVE-2026-... are still showing "Needs evaluation" for the golang packages, but they contain a comment by Marc Deslauriers: "Packages built using golang need to be rebuilt once the vulnerability has been fixed."

Alpine has bumped build numbers, as Chad Dougherty wrote here From: Chad Dougherty <crd477 () icloud com> Not an advisory, but Alpine did this: https://git.alpinelinux.org/aports/commit/?h=3.23-stable&id=f43ed43f4d329cb8cbca59b90c9560ab9e6d8f42 Alpine also had fresh releases on 2026-04-15, including some updates "rebuild with Go ..."

Arch linux appears not to have recompiled Go applications (or at least not all of them, only checked restic)

repo.almalinux.org does not show updated golang versions, so probably no recompiled Go applications either. There are multiple opensource distributions that do choose to rebuild all go binaries / applications / packages upon CVEs in the stdlib or in any of the dependencies. As an example (shameless plug) for Wolfi & Chainguard - one can see over 400 builds for https://images.chainguard.dev/security/CVE-2026-33810

It helps a lot to keep symbols tables in the binaries in general, because then govulncheck on the runtime binaries can determine false positives for the unused symbols - see demonstration of that in Build Better Go release binaries at fosdem - https://archive.fosdem.org/2025/schedule/event/fosdem-2025-4406-build-better-go-release-binaries/. In that presentation I have used coredns v1.11.1 which at the time would show 15 vulnerabilities when symbols tables are stripped; and 8 vulnerabilities if symbols tables are preserved. The difference is likely larger now.

I did not find similar granularity for CVEs in the stdlib - it would be nice if govulncheck had symbol level information for the go stdlib vulnerabilities; such that binaries that do not call particular functions do not trip up the scanners; and can be auto-marked as false positives; and thus not requiring rebuilds to pick up a newer 1.26.(n+1) in their build info metadata. From CVE scanning point of view symbols tables are nice, but they do increase the binary size and thus runtime memory usage when the binary is loaded / executed. I wish for detached symbols tables to be supported, similar to detached debug symbols - but I have not checked how to manually (with like patchelf) or automatically to produce that, and if scanners would resolve and support loading detached symbols tables. That would help providing these by default for scanners, without the runtime memory usage impact.

The other thing is that likely there can be more agresive LTO improvements, as currently go toolchain is concervative w.r.t. modules and symbols linked; but given govulncher often says that a module and symbol is imported but not used - it seems that there could be less things linked into the binaries in the first place, reducing CVEs. An extreme case was removing a single unused file in a dependency which wasn't called or used at all https://github.com/opencontainers/runc/pull/5056 (merged and backported via other prs, based on discussions there) resulting in a 6.7% decrease in the runc binary size.

Fewer symbols linked in binaries, and symbol level CVEs for stdlib would greatly improve go CVE management and reduce the need to mass rebuild everything.

Regards,

Dimitri.

On Sun, Apr 19, 2026 at 10:46:43PM +0200, Matthias Ferdinand wrote: Arch linux appears not to have recompiled Go applications (or at least not all of them, only checked restic) We don't.

I originall did this work a few years ago but it just produced a huge list of packages that would need to be worked through that carried other issues. The build infra is not there to dispatch larger rebuilds for this and all of it would be hand holding.

There are 431 depending on go, and each project would need to be unpacked/scanned and then rebuilt accordingly.

You could just rebuild everything, but that alone would take a few days depending on volunteer time.

-- Morten Linderud PGP: 9C02FF419FECBE16

On 4/20/26 12:07, Morten Linderud wrote: On Sun, Apr 19, 2026 at 10:46:43PM +0200, Matthias Ferdinand wrote: Arch linux appears not to have recompiled Go applications (or at least not all of them, only checked restic) We don't.

I originall did this work a few years ago but it just produced a huge list of packages that would need to be worked through that carried other issues. The build infra is not there to dispatch larger rebuilds for this and all of it would be hand holding.

There are 431 depending on go, and each project would need to be unpacked/scanned and then rebuilt accordingly.

You could just rebuild everything, but that alone would take a few days depending on volunteer time. I wonder if build infra needs to be updated to support automated rebuilds when a reverse dependency is updated. My understanding is that FreeBSD ports, Nix, and OBS already support this.

There is a very strong trend towards static linking, and even when dynamic linking is used, ABI stability might not be guaranteed.

I agree that this is extra work for distros, but I don't think distros will be able to convince upstreams to prioritize ABI stability for general libraries (as opposed to special cases). I'll write up a blog post about this later. -- Sincerely, Demi Marie Obenour (she/her/hers)

On 2026-04-20 13:10:13, Demi Marie Obenour wrote: I wonder if build infra needs to be updated to support automated rebuilds when a reverse dependency is updated. My understanding is that FreeBSD ports, Nix, and OBS already support this. On its own this isn't sufficient because many packages pin their dependencies to specific versions or git commits. This causes a cascade of problems:

Most dependencies can't be packaged separately, because eventually two applications will require two different versions of the same library, not to mention the labor involved.

You can try to loosen the dependency constraints yourself, but with everyone else bundling, no one cares about API/ABI stability and breakage is likely.

OTOH with dependencies left bundled and pinned to specific versions, rebuilding does nothing except change mtimes.

On 4/21/26 07:36, Michael Orlitzky wrote: On 2026-04-20 13:10:13, Demi Marie Obenour wrote: I wonder if build infra needs to be updated to support automated rebuilds when a reverse dependency is updated. My understanding is that FreeBSD ports, Nix, and OBS already support this. On its own this isn't sufficient because many packages pin their dependencies to specific versions or git commits. This causes a cascade of problems:

Most dependencies can't be packaged separately, because eventually two applications will require two different versions of the same library, not to mention the labor involved. I believe Fedora manages to package multiple versions of Rust libraries without any problems. They don't ship them to users, though. You can try to loosen the dependency constraints yourself, but with everyone else bundling, no one cares about API/ABI stability and breakage is likely.

OTOH with dependencies left bundled and pinned to specific versions, rebuilding does nothing except change mtimes. At least Rust libraries generally do care about API stability. You're correct that nobody cares about ABI stability, but cascading rebuilds are exactly what that is meant to avoid. 'cargo install' doesn't use the lockfile by default, so problems with newer but semver-compatible dependency versions are likely to be caught.

I don't know if the Go ecosystem has the same problem. I know Maven does have that problem. -- Sincerely, Demi Marie Obenour (she/her/hers)

-------- Forwarded Message -------- Subject: [security] Go 1.26.4 and Go 1.25.11 are released Date: Tue, 2 Jun 2026 21:11:30 +0000 From: announce () golang org To: golang-nuts () googlegroups com

Hello gophers,

We have just released Go versions 1.26.4 and 1.25.11, minor point releases.

These releases include 3 security fixes following the security policy <https://go.dev/doc/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/p4p3rhak>) 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

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

Thanks to everyone who contributed to the releases.

Cheers, The Go team

-- You received this message because you are subscribed to the Google Groups "golang-announce" group. To view this discussion visit https://groups.google.com/d/msgid/golang-announce/b412db1a.BAAACMDeKCEAAAAAAAAAA-p9MGAAAYKKSQYAAAAAADE8OwBqH0cC%40mailjet.com

-------- Forwarded Message -------- Subject: [security] Go 1.26.5 and Go 1.25.12 are released Date: Tue, 7 Jul 2026 20:22:04 +0000 From: announce () golang org To: golang-nuts () googlegroups com

Hello gophers,

We have just released Go versions 1.26.5 and 1.25.12, minor point releases.

These releases include 2 security fixes following the security policy <https://go.dev/doc/security/policy>:

os: Root escape via symlink plus trailing slash

On Unix systems, opening a file in an os.Root improperly followed symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.

For example, |root.Open("symlink/")| would open "symlink" even when "symlink" is a symbolic link pointing outside of the root.

On Unix, |openat(fd, path, ONOFOLLOW)| will follow symlinks in |path| when |path| ends in a /. Root failed to account for this behavior, permitting paths with a trailing / to escape. It now properly sanitizes the path parameter provided to openat.

Thanks to Mundur <https://github.com/M0nd0R> forreporting this issue.

This is CVE-2026-39822 and Go issue <https://go.dev/issue/79005>.

crypto/tls: Encrypted Client Hello privacy leak

The Encrypted Client Hello implementation would leak the pre-shared key identities during the handshake, allowing a passive network observer who can collect handshakes to de-anonymize the hostname of the server, even when ECH was being used.

Thanks to Coia Prant (github.com/rbqvq) for reporting this issue.

This is CVE-2026-42505 and Go issue <https://go.dev/issue/79282>.

View the release notes for more information: https://go.dev/doc/devel/release#go1.26.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.26.5| and build as usual.

Thanks to everyone who contributed to the releases.

Cheers, Junyang and David for the Go team

-- You received this message because you are subscribed to the Google Groups "golang-announce" group. To view this discussion visit https://groups.google.com/d/msgid/golang-announce/f9a3d5eb.CAAACOz5h5QAAAAAAAAAA-p9MGAAAYKKSQYAAAAAADE8OwBqTVs%40mailjet.com <https://groups.google.com/d/msgid/golang-announce/f9a3d5eb.CAAACOz5h5QAAAAAAAAAA-p9MGAAAYKKSQYAAAAAADE8OwBqTVs%40mailjet.com?utmmedium=email&utmsource=footer>.

Latest version: 1.27.1