3541b0d0fd
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>
The Moby Project
Moby is an open-source project created by Docker to enable and accelerate software containerization.
It provides a "Lego set" of toolkit components, the framework for assembling them into custom container-based systems, and a place for all container enthusiasts and professionals to experiment and exchange ideas. Components include container build tools, a container registry, orchestration tools, a runtime and more, and these can be used as building blocks in conjunction with other tools and projects.
Principles
Moby is an open project guided by strong principles, aiming to be modular, flexible and without too strong an opinion on user experience. It is open to the community to help set its direction.
- Modular: the project includes lots of components that have well-defined functions and APIs that work together.
- Batteries included but swappable: Moby includes enough components to build fully featured container systems, but its modular architecture ensures that most of the components can be swapped by different implementations.
- Usable security: Moby provides secure defaults without compromising usability.
- Developer focused: The APIs are intended to be functional and useful to build powerful tools. They are not necessarily intended as end user tools but as components aimed at developers. Documentation and UX is aimed at developers not end users.
Audience
The Moby Project is intended for engineers, integrators and enthusiasts looking to modify, hack, fix, experiment, invent and build systems based on containers. It is not for people looking for a commercially supported system, but for people who want to work and learn with open source code.
Relationship with Docker
The components and tools in the Moby Project are initially the open source components that Docker and the community have built for the Docker Project. New projects can be added if they fit with the community goals. Docker is committed to using Moby as the upstream for the Docker Product. However, other projects are also encouraged to use Moby as an upstream, and to reuse the components in diverse ways, and all these uses will be treated in the same way. External maintainers and contributors are welcomed.
The Moby project is not intended as a location for support or feature requests for Docker products, but as a place for contributors to work on open source code, fix bugs, and make the code more useful. The releases are supported by the maintainers, community and users, on a best efforts basis only. For customers who want enterprise or commercial support, Docker Desktop and Mirantis Container Runtime are the appropriate products for these use cases.
Legal
Brought to you courtesy of our legal counsel. For more context, please see the NOTICE document in this repo.
Use and transfer of Moby may be subject to certain restrictions by the United States and other governments.
It is your responsibility to ensure that your use and/or transfer does not violate applicable laws.
For more information, please see https://www.bis.doc.gov
Licensing
Moby is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.