This releases 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
View the release notes for more information:
https://go.dev/doc/devel/release#go1.25.6
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Fixes warning:
```
time="2025-11-06T11:22:30Z" level=warning msg="Template locator \"template://oraclelinux-8\" should be written \"template:oraclelinux-8\" since Lima v2.0"
```
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>
Includes a change to use go.dev/dl instead of storage.googleapis.com/golang
as fallback URL, because storage.googleapis.com/golang is deprecated.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Don't build the dev image separately for each validation.
Build it once and then cache it so the validations can reuse it.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Allow other validate checks to finish even if one of them failed.
Sometimes a check is faulty and its failure is expected - in such case
we want to ignore that one validation fail but still run all the others.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Jaeger does not make it easy to dump all the collected trace spans from
all services at once. Switch to using the OpenTelemetry Collector with
the OTLP File exporter which writes the traces straight to disk in a
format that Jaeger UI can natively consume.
Signed-off-by: Cory Snider <csnider@mirantis.com>
bin-image workflow was failing for the new docker tags
(`docker-v29.0.0-rc.2`) because it wasn't correctly picked up by the
condition that should filter out tags.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
- relates to 96b29f5a1f
- similar to 08e4e88482
The daemon currently provides support for API versions all the way back
to v1.24, which is the version of the API that shipped with docker 1.12.0
(released in 2016).
Such old versions of the client are rare, and supporting older API versions
has accumulated significant amounts of code to remain backward-compatible
(which is largely untested, and a "best-effort" at most).
This patch updates the minimum API version to v1.44, matching the minimum
version of the client, and matching the API version of docker v25.0, which
is the oldest supported version (through Mirantis MCR).
The intent is to start deprecating older API versions when daemons implementing
them reach EOL. This patch does not yet remove backward-compatibility code
for older API versions, and the DOCKER_MIN_API_VERSION environment variable
allows overriding the minimum version (to allow restoring the behavior from
before this patch), however, API versions below v1.44 should be considered
"best effort", and we may remove compatibility code to provide "degraded"
support.
With this patch the daemon defaults to API v1.44 as minimum:
docker version
Client:
Version: 28.5.0
API version: 1.51
Go version: go1.24.7
Git commit: 887030f
Built: Thu Oct 2 14:54:39 2025
OS/Arch: linux/arm64
Context: default
Server:
Engine:
Version: dev
API version: 1.52 (minimum version 1.44)
....
Trying to use an older version of the API produces an error:
DOCKER_API_VERSION=1.43 docker version
Client:
Version: 28.5.0
API version: 1.43 (downgraded from 1.51)
Go version: go1.24.7
Git commit: 887030f
Built: Thu Oct 2 14:54:39 2025
OS/Arch: linux/arm64
Context: default
Error response from daemon: client version 1.43 is too old. Minimum supported API version is 1.44, please upgrade your client to a newer version
To restore the previous minimum, users can start the daemon with the
DOCKER_MIN_API_VERSION environment variable set:
DOCKER_MIN_API_VERSION=1.24 dockerd
API 1.24 is the oldest supported API version;
docker version
Client:
Version: 28.5.0
API version: 1.24 (downgraded from 1.51)
Go version: go1.24.7
Git commit: 887030f
Built: Thu Oct 2 14:54:39 2025
OS/Arch: linux/arm64
Context: default
Server:
Engine:
Version: dev
API version: 1.52 (minimum version 1.24)
....
When using the `DOCKER_MIN_API_VERSION` with a version of the API that
is not supported, an error is produced when starting the daemon;
DOCKER_MIN_API_VERSION=1.23 dockerd --validate
invalid DOCKER_MIN_API_VERSION: minimum supported API version is 1.24: 1.23
DOCKER_MIN_API_VERSION=1.99 dockerd --validate
invalid DOCKER_MIN_API_VERSION: maximum supported API version is 1.52: 1.99
Specifying a malformed API version also produces the same error;
DOCKER_MIN_API_VERSION=hello dockerd --validate
invalid DOCKER_MIN_API_VERSION: minimum supported API version is 1.24: hello
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
The sync-labels option was causing the labeler action to remove labels
that were manually added by humans.
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>
The Windows test workflow jobs were missing the dependency on the
`validate-dco` job so they ran regardless whether the DCO check passed
or not.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
`vm` is quite lengthy which makes it impossible to restart other failed
(flaky) jobs from the `test` workflow before the `vm` finishes.
This patch moves it to a separate workflow to allow retrying other jobs
independently.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Sets up the labeler workflow to automatically label PRs affecting the
`client` and `api` modules.
This allows to distinguish PRs targetting different modules.
TODO: Figure out how to handle PRs that would end up with both labels.
However, I think it's good to see what PRs would that affect.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
commit f0c069ffc9 added support for a
`ci/validate-only` label to skip tests and only run the validation checks.
Commit 09ecd74cf3 was merged later, but was
authored before that feature was merged, so did not account for the label,
so the "vm" checks would always run.
This applies the additional conditions to skip the "vm" checks if the
`ci/validate-only` label is set.
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>
Lima is used for running a VM of `template://oraclelinux-8`.
My initial attempt was to use almalinux-8, but some port forwarding tests
do not seem to work on almalinux-8.
https://lima-vm.io/docs/examples/gha/
Fix issue 49576
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This change adds conditional logic to skip build and test jobs when a
pull request is labeled with 'ci/validate-only'.
The `govulncheck` job in the CI workflow is intentionally excluded from
this conditional logic, ensuring security vulnerability checks always
run regardless of the label.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The PR validation workflow now enforces that every PR with an 'impact/*'
label must also have a corresponding 'kind/*' label, in addition to the
existing 'area/*' label requirement.
This change helps ensure proper categorization of pull requests by
requiring contributors to specify both the impact area and the kind of
change being made.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
