The http.Client passed into client.WithHTTPClient() is modified by the
constructor in-place: the value of its Transport field is mutated and
wrapped in an OpenTelemetry decorator. This can lead to very surprising
behaviour when a second client is constructed reusing the same
http.Client value. If the http.Client is configured for TLS, the second
client will fail to detect that and will incorrectly dial the Engine API
socket as cleartext HTTP. Copy the provided http.Client so our
modifications don't leak out to unexpected places.
Signed-off-by: Cory Snider <csnider@mirantis.com>
WARN [runner/exclusion_rules] Skipped 0 issues by rules: [Text: "type name will be used as (container|volume)\\.(Container|Volume).* by other packages, and that stutters; consider calling this", Path: "api/types/(volume|container)/", Linters: "revive"]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove the hardcoded concurrency limit of 2 from the golangci-lint
configuration to allow the linter to match the machine CPU's core count.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
These releases include 2 security fixes following the security policy:
- crypto/x509: excessive resource consumption in printing error string for host certificate validation
Within HostnameError.Error(), when constructing an error string, there is no limit to the number of hosts that will be printed out.
Furthermore, the error string is constructed by repeated string concatenation, leading to quadratic runtime.
Therefore, a certificate provided by a malicious actor can result in excessive resource consumption.
HostnameError.Error() now limits the number of hosts and utilizes strings.Builder when constructing an error string.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61729 and Go issue https://go.dev/issue/76445.
- crypto/x509: excluded subdomain constraint does not restrict wildcard SANs
An excluded subdomain constraint in a certificate chain does not restrict the
usage of wildcard SANs in the leaf certificate. For example a constraint that
excludes the subdomain test.example.com does not prevent a leaf certificate from
claiming the SAN *.example.com.
This is CVE-2025-61727 and Go issue https://go.dev/issue/76442.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This release addresses breakage caused by a security patch included in
Go 1.25.2 and 1.24.8, which enforced overly restrictive validation on
the parsing of X.509 certificates. We've removed those restrictions
while maintaining the security fix that the initial release addressed.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This minor release includes 10 security fixes following the security policy:
- net/mail: excessive CPU consumption in ParseAddress
The ParseAddress function constructed domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this could cause excessive CPU consumption.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2025-61725 and Go issue https://go.dev/issue/75680.
- crypto/x509: quadratic complexity when checking name constraints
Due to the design of the name constraint checking algorithm, the processing time
of some inputs scales non-linearly with respect to the size of the certificate.
This affects programs which validate arbitrary certificate chains.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58187 and Go issue https://go.dev/issue/75681.
- crypto/tls: ALPN negotiation errors can contain arbitrary text
The crypto/tls conn.Handshake method returns an error on the server-side when
ALPN negotation fails which can contain arbitrary attacker controlled
information provided by the client-side of the connection which is not escaped.
This affects programs which log these errors without any additional form of
sanitization, and may allow injection of attacker controlled information into
logs.
Thanks to National Cyber Security Centre Finland for reporting this issue.
This is CVE-2025-58189 and Go issue https://go.dev/issue/75652.
- encoding/pem: quadratic complexity when parsing some invalid inputs
Due to the design of the PEM parsing function, the processing time for some
inputs scales non-linearly with respect to the size of the input.
This affects programs which parse untrusted PEM inputs.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61723 and Go issue https://go.dev/issue/75676.
- net/url: insufficient validation of bracketed IPv6 hostnames
The Parse function permitted values other than IPv6 addresses to be included in square brackets within the host component of a URL. RFC 3986 permits IPv6 addresses to be included within the host component, enclosed within square brackets. For example: "http://[::1]/". IPv4 addresses and hostnames must not appear within square brackets. Parse did not enforce this requirement.
Thanks to Enze Wang, Jingcheng Yang and Zehui Miao of Tsinghua University for reporting this issue.
This is CVE-2025-47912 and Go issue https://go.dev/issue/75678.
- encoding/asn1: pre-allocating memory when parsing DER payload can cause memory exhaustion
When parsing DER payloads, memories were being allocated prior to fully validating the payloads.
This permits an attacker to craft a big empty DER payload to cause memory exhaustion in functions such as asn1.Unmarshal, x509.ParseCertificateRequest, and ocsp.ParseResponse.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58185 and Go issue https://go.dev/issue/75671.
- net/http: lack of limit when parsing cookies can cause memory exhaustion
Despite HTTP headers having a default limit of 1 MB, the number of cookies that can be parsed did not have a limit.
By sending a lot of very small cookies such as "a=;", an attacker can make an HTTP server allocate a large amount of structs, causing large memory consumption.
net/http now limits the number of cookies accepted to 3000, which can be adjusted using the httpcookiemaxnum GODEBUG option.
Thanks to jub0bs for reporting this issue.
This is CVE-2025-58186 and Go issue https://go.dev/issue/75672.
- crypto/x509: panic when validating certificates with DSA public keys
Validating certificate chains which contain DSA public keys can cause programs
to panic, due to a interface cast that assumes they implement the Equal method.
This affects programs which validate arbitrary certificate chains.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-58188 and Go issue https://go.dev/issue/75675.
- archive/tar: unbounded allocation when parsing GNU sparse map
tar.Reader did not set a maximum size on the number of sparse region data blocks in GNU tar pax 1.0 sparse files. A maliciously-crafted archive containing a large number of sparse regions could cause a Reader to read an unbounded amount of data from the archive into memory. When reading from a compressed source, a small compressed input could result in large allocations.
Thanks to Harshit Gupta (Mr HAX) - https://www.linkedin.com/in/iam-harshit-gupta/ for reporting this issue.
This is CVE-2025-58183 and Go issue https://go.dev/issue/75677.
- net/textproto: excessive CPU consumption in Reader.ReadResponse
The Reader.ReadResponse function constructed a response string through
repeated string concatenation of lines. When the number of lines in a response is large,
this could cause excessive CPU consumption.
Thanks to Jakub Ciolek for reporting this issue.
This is CVE-2025-61724 and Go issue https://go.dev/issue/75716.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This package was aliased as "imagespec" in some places, and "dockerspec"
in other places, which made it easy to confuse.
Change all uses of this package to be aliased as "dockerspec" and configure
an "importas" linting check to enforce it.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This includes 1 security fix:
- net/http: CrossOriginProtection bypass patterns are over-broad
When passing patterns to CrossOriginProtection.AddInsecureBypassPattern,
requests that would have redirected to those patterns (e.g. without a trailing
slash) were also exempted, which might be unexpected.
Thanks to Marco Gazerro for reporting this issue.
This is CVE-2025-47910 and Go issue https://go.dev/issue/75054.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.7
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The github.com/docker/docker/reference package was moved to
github.com/moby/moby/v2/daemon/internal/refstore, so this
check no longer did anything (and no aliasing needed).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.4...go1.24.5
This minor releases include 1 security fixes following the security policy:
- cmd/go: unexpected command execution in untrusted VCS repositories
Various uses of the Go toolchain in untrusted VCS repositories can result in
unexpected code execution. When using the Go toolchain in directories fetched
using various VCS tools (such as directly cloning Git or Mercurial repositories)
can cause the toolchain to execute unexpected commands, if said directory
contains multiple VCS configuration metadata (such as a '.hg' directory in a Git
repository). This is due to how the Go toolchain attempts to resolve which VCS
is being used in order to embed build information in binaries and determine
module versions.
The toolchain will now abort attempting to resolve which VCS is being used if it
detects multiple VCS configuration metadata in a module directory or nested VCS
configuration metadata (such as a '.git' directoy in a parent directory and a
'.hg' directory in a child directory). This will not prevent the toolchain from
building modules, but will result in binaries omitting VCS related build
information.
If this behavior is expected by the user, the old behavior can be re-enabled by
setting GODEBUG=allowmultiplevcs=1. This should only be done in trusted
repositories.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting
this issue.
This is CVE-2025-4674 and https://go.dev/issue/74380.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The IdentityMapping and Identity types are still used internally, but
should be considered transitional.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.3...go1.24.4
This release includes 3 security fixes following the security policy:
- net/http: sensitive headers not cleared on cross-origin redirect
Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue.
This is CVE-2025-4673 and Go issue https://go.dev/issue/73816.
- os: inconsistent handling of O_CREATE|O_EXCL on Unix and Windows
os.OpenFile(path, os.O_CREATE|O_EXCL) behaved differently on Unix and Windows systems when the target path was a dangling symlink. On Unix systems, OpenFile with O_CREATE and O_EXCL flags never follows symlinks. On Windows, when the target path was a symlink to a nonexistent location, OpenFile would create a file in that location.
OpenFile now always returns an error when the O_CREATE and O_EXCL flags are both set and the target path is a symlink.
Thanks to Junyoung Park and Dong-uk Kim of KAIST Hacking Lab for discovering this issue.
This is CVE-2025-0913 and Go issue https://go.dev/issue/73702.
- crypto/x509: usage of ExtKeyUsageAny disables policy validation
Calling Verify with a VerifyOptions.KeyUsages that contains ExtKeyUsageAny unintentionally disabledpolicy validation. This only affected certificate chains which contain policy graphs, which are rather uncommon.
Thanks to Krzysztof Skrzętnicki (@Tener) of Teleport for reporting this issue.
This is CVE-2025-22874 and Go issue https://go.dev/issue/73612.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
