Add a Go converter in a separate tooling module and reintroduce
swagger.yaml as generated Swagger 2.0 output. Preserve schema property
order, examples, and generator extensions, and reject unsupported
constructs. Use the union of response media types for Swagger's
operation-wide produces lists.
Leave historical versioned specifications and generated Go models
unchanged.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
These releases include 1 security fix following the security policy:
- crypto/x509: mitigation for security concerns with a specific Certificate Authority
We're blocking trust in a small set of intermediate certificates due to specific security concerns around their operation.
Verify will now filter out chains which contain these intermediates, preventing them from being returned to the caller.
We highly recommend immediately upgrading to this release.
This is CVE-2026-111943 and Go issue https://go.dev/issue/82345.
release notes: https://go.dev/doc/devel/release#go1.26.10
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The regular expression used to exclude non-shell files is too greedy,
resulting in some shell scripts being excluded from the check:
- hack/validate/vendor and hack/vendor.sh (matched "vendor");
- hack/make/.go-autogen (matched ".go").
Use git pathspec instead, excluding the vendor directory and Python
files only. Drop .go, .bats, and Jenkinsfile exclusions, as there
are no such files having a shebang line.
Note that using "shfmt -f ." to find shell scripts is not an option, as it
skips dot-files (e.g. hack/make/.binary) even with --detect=all, and
scripts with a non-standard shebang (contrib/init/openrc/docker.initd).
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
A slightly greedy grep statement in hack/validate/shfmt (to be fixed by
the next commit) resulted in these files being excluded from formatting.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Instead of asking a user to run a shfmt with a handful of options, let's
just allow to run hack/validate/shfmt with -w, making it write the
changes (in addition to showing them).
Now, the path component of $0 might differ from that of a user, but this
is still a good hint at where to look for the script.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
shellcheck complains:
> In hack/validate/shfmt line 7:
> if git grep --name-only '^#!' | egrep -v '(vendor|\.go|Jenkinsfile|\.py|\.bats)' \
> ^---^ SC2196 (info): egrep is non-standard and deprecated. Use grep -E instead.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Fix the following shellcheck warning:
> In hack/validate/shfmt line 8:
> | xargs shfmt -d $shfmtflags; then
> ^---------^ SC2086 (info): Double quote to prevent globbing and word splitting.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Currently, hack/validate/default and hack/validate/all source all the
scripts, thus making them part of the current one.
This is wrong for a number of reasons, the main one being any script
being sourced can make changes in the current shell thus influencing all
the scripts that are sourced after it. For example, any script sourced
can set or unset shell variables, change shell options, or just exit.
In fact, four of the scripts have exit statement:
$ git grep -w exit hack/validate/
hack/validate/module-replace: exit 1
hack/validate/pr-gh-references: exit 1
hack/validate/shfmt: exit 1
hack/validate/vendor: exit 1
and most of the others have `set -e` and/or `set -o pipefail`.
This means that if there is any error from any of the scripts,
or even just innocent "exit 0"), all the script below won't be
executed.
To fix this, while still making the "mega" script return an error, let's
run those scripts one by one, checking their exit codes, and exit with
the last non-zero exit code, if any (or 0, if all scripts exited with 0).
While at it, fix some issues reported by shellcheck.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
These releases include 15 security fixes following the security policy:
- net/http: HTTP/2 server crash due to HPACK encoder race
HTTP/2 servers could end up crashing due to inadvertently
modifying its HPACK encoder concurrently. This happens because the
server modifies the HPACK encoder from two goroutines without
synchronization: one uses the encoder to encode a HEADERS frame as part
of a response sent to a client and the other modifies the encoder's
table size when handling a SETTINGS frame containing
SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can
repeatedly send a request while changing the header table size to crash
the server.
Fix this issue by not applying SETTINGS_HEADER_TABLE_SIZE immediately.
Instead, buffer any SETTINGS_HEADER_TABLE_SIZE received, and only apply
the new value prior to the next time the server writes a frame.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for reporting this issue.
This is CVE-2026-97032 and Go issue https://go.dev/issue/81867.
- net/http: HTTP/2 server memory exhaustion due to Trailer headers
When "Trailer" headers are sent by a client, the HTTP server internally
uses the header values to populate the Request.Trailer map passed to the
server handler. Because Request.Trailer is a map, each entry incurs
memory overhead. For HTTP/2 servers, a malicious client can exploit this
by sending a "Trailer" header that declares a large number of fields,
causing the server to allocate a disproportionate amount of memory while
bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits.
This exploit is not applicable for HTTP/1 servers, which do not support
multiplexing a large number of requests over one TCP connection, and
whose Server.MaxHeaderBytes are calculated differently.
Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits are now
applied towards the trailer fields declared in "Trailer" headers.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc. for reporting this issue.
This is CVE-2026-78659 and Go issue https://go.dev/issue/81857.
- crypto/tls: reject malformed ECH outer extension references
Multiple ECH outer extension references are not
permitted under RFC 9849; previously, a client
could send a well-crafted packet that could
trigger memory exhaustion in the server process
by specifying multiple references.
We now reject these as malformed and curb the
memory amplification vector as a result.
This is CVE-2026-97031 and Go issue https://go.dev/issue/81855.
- cmd/go: checksum bypass for golang.org/fips140
Previously, a user operating inside of a malicious
Go project that defines a bogus golang.org/fips140
and operates a malicious GOMODPROXY the user chooses
to connect to can serve an arbitrary module in its
place.
We now unpack the trusted ziphash for the bundled
golang.org/fips140 module and construct its entry
in the GOMODCACHE such that it can be verified by
the toolchain.
This is CVE-2026-94444 and Go issue https://go.dev/issue/81833.
- cmd/go: checksum database bypass for golang.org/toolchain
Previously, a user operating inside of a malicious
Go project that defines a bogus golang.org/toolchain
go.sum entry and operates a malicious GOMODPROXY the
user chooses to use can bypass the intended checksum.
We now ensure that golang.org/toolchain always goes
to the network for the canonical checksum.
This is CVE-2026-94447 and Go issue https://go.dev/issue/81834.
- html/template: reset context tracking on consecutive template expressions
When a JavaScript template literal contains
consecutive expressions, the context tracking
state was not properly reset upon entering a
new expression.
We now ensure that template-literal expression
entries correctly reset context variables so all
subsequent regular expression literals are
accurately recognized and escaped.
This is CVE-2026-94448 and Go issue https://go.dev/issue/81821.
- html/template: recognize yield as regexp preceder keyword
A trusted template author may have previously
written a valid template wherein the use of
the yield keyword would not be correctly
escaped.
We now ensure that valid keyword uses are
escaped and non-keyword uses are not escaped.
This is CVE-2026-97030 and Go issue https://go.dev/issue/81823.
- net/textproto, mime/multipart: memory limit bypass when parsing MIME headers
Parsing a multipart form could bypass memory limits and read an
arbitrarily long line into memory when the remaining limit at the
start of a part was less than 400 bytes.
Multipart form memory limits are now properly enforced in this situation.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-94440 and Go issue https://go.dev/issue/81741.
- net/http: HTTP/1 client connection desynchronization after CONNECT rejection
When http.Transport sends an HTTP/1 CONNECT request with a non-empty
Request.Body, it writes the body directly to the connection without
framing after the request headers. If the server rejects the CONNECT
request with a non-2xx keep-alive response, Transport returns the
connection to the idle pool. Because CONNECT requests do not have a
request body, the server may interpret the trailing body bytes as a
subsequent pipelined HTTP/1.1 request on the connection, leaving the
pooled connection desynchronized and causing the next caller that reuses
it to read the response to the injected request. In reverse proxies
(including httputil.ReverseProxy) that forward CONNECT requests through
a shared Transport, this can lead to cross-user response poisoning.
The HTTP/1 transport now closes a connection after sending a CONNECT
request, regardless of the response status.
In addition, ReverseProxy now rejects incoming CONNECT requests
with a 405 Method Not Allowed response. ReverseProxy has never handled
CONNECT requests in a useful fashion (it does not convert the
connection into a bidirectional tunnel), so we do not expect this
change to negatively affect any current users.
Thanks to Xclow3n (Rajat Raghav) for reporting this issue.
This is CVE-2026-56866 and Go issue https://go.dev/issue/81740.
- net/http: HTTP/1 server connection desynchronization after 2xx CONNECT response
When an HTTP server handler sent a 2xx response to an HTTP/1 CONNECT request
and returned without hijacking the connection, the server improperly continued
to read and serve requests from the connection. Since a 2xx response to an
HTTP/1 CONNECT converts the connection into a tunnel, the server should not
treat the connection as continuing to contain HTTP.
The impact of this misbehavior is mostly limited to potential request smuggling,
where an intermediate proxy considers the data on the connection to be tunneled
and the server considers it to be HTTP.
The HTTP/1 server now always closes a connection after responding to a CONNECT
request, regardless of the response status.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-94439 and Go issue https://go.dev/issue/81744.
- net/http: excessive CPU consumption from repeated initial window changes
A malicious HTTP/2 peer could cause excessive CPU consumption in the
client or server by opening a large number of streams and then sending
many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.
The HTTP/2 client and server now efficiently handle changes to the
initial window size (O(1) rather than O(number of streams)).
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-78669 and Go issue https://go.dev/issue/81742.
- net/http: HTTP/2 transport accepts malformed framing-related headers
Historically, we have been rather lax about malformed framing-related
headers in our HTTP/2 implementation, as they cannot interfere with
HTTP/2 framing. However, this makes it possible for our HTTP/2
implementation to forward responses containing such headers to an HTTP/1
client when acting as a reverse proxy. If the HTTP/1 client also does
not behave strictly enough, this can result in response smuggling.
We now delete malformed framing-related headers when received by our
HTTP/2 transport, so they will not be forwarded to a potentially
vulnerable HTTP/1 client.
Thanks to TJ Barton for reporting this issue.
This is CVE-2026-78660 and Go issue https://go.dev/issue/81115.
- os: Root.Mkdir(All) can follow junctions out of the root on Windows
On Windows, when the target of Root.Mkdir or Root.MkdirAll was a junction
pointing to an empty location, the operation would create a directory at
the junction target even when that target was located outside the root.
This only applies to operations where the last path component is a
junction (path/to/junction, but not path/junction/target).
Root.Mkdir and Root.MkdirAll now correctly avoid resolving junctions.
Thanks to Daniele Ballarini for reporting this issue.
This is CVE-2026-56857 and Go issue https://go.dev/issue/81739.
- net/http: lack of limit on size of parsed Range headers
When parsing a Range header containing a large number of small ranges,
FileServer(FS), ServeContent, and ServeFile(FS) could consume an excessive
amount of CPU.
These functions now ignore Range headers containing more than 200 ranges.
The limit is controlled by the new httpservecontentmaxranges=
GODEBUG setting. Setting GODEBUG=httpservecontentmaxranges=0
disables the limit.
Thanks to Jakub Ciolek (https://ciolek.dev) for reporting this issue.
This is CVE-2026-78667 and Go issue https://go.dev/issue/81858.
- net/http: double flow control refund on HTTP/2 server streams
The HTTP/2 server could refund connection-level flow control twice for the same data:
Once when a client resets a stream (refunding data for any sent-but-unread portion
of the stream), and again when a request handler reads the buffered data.
A malicious client could exploit this to bypass the configured connection-level
flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still
limited by the concurrent stream limit and stream-level flow control.
The HTTP/2 server now waits to refund connection-level flow control for reset
streams until after the request handler is complete.
Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276/) for reporting this issue.
This is CVE-2026-78663 and Go issue https://go.dev/issue/81743.
release notes: https://go.dev/doc/devel/release#go1.26.9
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Allow BUILDKIT_REPO and BUILDKIT_REF to override the values derived from
go.mod.
This makes it possible to temporarily test a different BuildKit repository
or version in CI without modifying go.mod.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
TestAccessPortPublishedOnLoopbackAddress and
TestDirectRemoteAccessOnExposedPort send UDP probes with "nc", which is
not installed on the almalinux-8 and opensuse-tumbleweed CI runners:
/bin/sh: nc: command not found
Install nmap-ncat (dnf) and netcat-openbsd (zypper) to provide it.
The two implementations don't report errors in the same way: nmap's ncat
exits non-zero when the probe gets an ICMP error (for example, when the
container's listener isn't ready yet), where OpenBSD's netcat - used by
the development container - exits 0. Asserting on the exit status would
therefore make these tests flaky on RHEL-like hosts. Log a failed probe
instead, and let the retry loop send the payload again. Check that netcat
is installed up-front, so that a missing "nc" is still reported clearly.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The vm workflow only covers oraclelinux-8, which is kept for cgroup v1.
Add openSUSE Tumbleweed to the matrix for a rolling-release host: a recent
kernel, SELinux in enforcing mode, and an iptables-nft based userspace.
Support SUSE-compatible guests in the provisioning script by selecting the
package manager and the packages that differ between the distributions.
Run the tests from /var/tmp, not /tmp. The latter is a tmpfs on SUSE, which
is too small for the test daemons' data roots and consumes the guest memory.
Look up selinuxenabled by absolute path, as /usr/sbin is not in the login
user's PATH on all distributions, and the rootless daemons were started with
overlay2 instead of fuse-overlayfs. Sanitize the template locator for the
report artifact names, which cannot contain the "/" of "experimental/".
Unset XDG_CONFIG_HOME and XDG_DATA_HOME before switching to the rootless
account. dockerd honors them when running with RootlessKit, and sudo
--preserve-env passes on the ones of the invoking user. SUSE sets them from
PAM, so they pointed at root's home, and the daemon failed to read its
configuration.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The VM jobs vary the kernel while running the daemon and tests inside the
Debian development image. This masks the guest's userspace, systemd, and
security configuration, limiting the host OS coverage of these jobs.
Build the pinned dependency bundle on the runner, provision native guest
packages and the rootless account, and invoke the harness in the guest.
The development image and make previously supplied the tools, account,
Git configuration, and GitHub Actions environment; native execution needs
these set up explicitly. Use fuse-overlayfs for rootless SELinux guests.
Install the bundle as root without overwriting existing guest directory
metadata, and make bundles/ traversable before copying the checkout.
BuildKit exports have runner ownership and mode 0700, including newly
created parents. DIND did not extract these onto the guest or copy their
permissions into daemon binary and data paths. Move the export outside
the checkout so source and report copies exclude build dependencies.
Document provisioning and native integration test commands for local VMs.
Assisted-by: Codex
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Cleanup uses the umount supplied by the Debian development image, which
accepts -q. Native execution on Oracle Linux 8 uses an older util-linux
that rejects this option, preventing cleanup from attempting the unmount.
Redirect stderr instead of requiring -q, retaining best-effort cleanup
when the daemon root is already unmounted.
Assisted-by: Codex
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The development container controls both the installed binaries and sudo's
search path. On native hosts, secure_path can select a packaged launcher
or omit our tools. Older sudo versions also use secure_path to find the
command even when PATH is preserved for the command's environment.
Resolve the launcher before invoking sudo and preserve the test PATH in
both the main harness and the per-test daemon helper. This keeps the
launcher and its child processes using the binaries under test.
Assisted-by: Codex
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Kernel module loading and guest package setup are embedded in the VM
workflow. This was sufficient when the guest only hosted the DIND
development container, but native testing needs provisioning that can
also be run and checked outside GitHub Actions.
Move the existing commands into hack/host scripts, executed as root in
the guest. Keep the socket's login user supplied by the runner so this
preparatory refactor preserves the existing Docker setup.
Assisted-by: Codex
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Update our Dockerfile to use debian 13 as base. Some notes about architectures
from the [announcement][1];
> This release for the first time officially supports the riscv64 architecture,
> allowing users to run Debian on 64-bit RISC-V hardware and benefit from all
> Debian 13 features. A total of seven architectures are officially supported
> for trixie:
>
> - 64-bit PC (amd64),
> - 64-bit ARM (arm64),
> - ARM EABI (armel),
> - ARMv7 (EABI hard-float ABI, armhf),
> - 64-bit little-endian PowerPC (ppc64el),
> - 64-bit little-endian RISC-V (riscv64),
> - IBM System z (s390x)
>
> i386 is no longer supported as a regular architecture: there is no official
> kernel and no Debian installer for i386 systems. The i386 architecture is
> now only intended to be used on a 64-bit (amd64) CPU. Users running i386
> systems should not upgrade to trixie. Instead, Debian recommends either
> reinstalling them as amd64, where possible, or retiring the hardware.
>
> trixie will be the last release for the armel architecture. See
> [5.1.3. Last release for armel][2] in the release notes for more information
> on our ARM EABI support.
Also install e2fsprogs to fix missing mkfs.ext4
[1]: https://www.debian.org/News/2025/20250809
[2]: https://www.debian.org/releases/trixie/release-notes/issues.html#last-release-for-armel
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
GO111MODULE=off was added when generation ran inside GOPATH with
vendor.mod workarounds. Generation now runs outside GOPATH, those
workarounds are gone, and tools are declared in go.mod, so keep module
mode enabled to resolve them through `go tool`.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Use grep's text mode when locating tests matching TEST_FILTER.
The search is restricted to *_test.go files, which are known to be text.
Using -I allowed grep's binary-file detection heuristic to silently ignore
matching source files, causing the corresponding integration test suites to
be skipped.
For example, grep may report a Go test file:
$ grep -nE 'func .*TestRunWriteSpecialFilesAndNotCommit.*' \
integration-cli/docker_cli_run_test.go
grep: integration-cli/docker_cli_run_test.go: binary file matches
Forcing text mode finds the expected test:
$ grep -anE 'func .*TestRunWriteSpecialFilesAndNotCommit.*' \
integration-cli/docker_cli_run_test.go
1713:func (s *DockerCLIRunSuite) TestRunWriteSpecialFilesAndNotCommit(c *testing.T) {
This caused TEST_FILTER not to find a test, and skipping all tests;
make TEST_FILTER=TestRunWriteSpecialFilesAndNotCommit test-integration
...
---> Making bundle: test-integration (in bundles/test-integration)
Skipping integration tests since the supplied filter "TestRunWriteSpecialFilesAndNotCommit" omits all integration tests
Skipping integration-cli tests since the supplied filter "TestRunWriteSpecialFilesAndNotCommit" omits all integration-cli tests
integration and integration-cli skipped according to env vars
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This release includes a fix to address a breakage affecting unencrypted
HTTP/2 (h2c) connections caused by a security patch included in last
patch release.
See go.dev/issue/80876 for details.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This release includes 10 security fixes following the security policy:
- x/mod/sumdb/tlog: fix transparency log tile verification bypass
A malicious GOPROXY was previously capable of forging
up to two sumdb tiles that allow for a requested module
to bypass the GOSUMDB check and persist attacker-controlled
module content to a local Go module cache.
This attack allows for a malicious GOPROXY to serve
malicious module content that cannot be detected
by evaluating the transparency log.
All tiles are now correctly verified against their parents.
In order to determine if you have been affected:
rm -r go.sum go.work.sum vendor/ && go mod tidy
Thanks to Filippo Valsorda (Geomys) for reporting this issue.
This is CVE-2026-56865 and Go issue https://go.dev/issue/80744.
- x/mod/sumdb: ignore unrelated, unauthenticated hashes in Lookup
A malicious GOSUMDB was capable of serving arbitrary
module content not contained within the transparency
log.
This attack allows for a coordinating GOPROXY and
GOSUMDB to serve a client malicious module content
that cannot be detected by evaluating the transparency
log.
In order to determine if you have been affected:
rm -r go.sum go.work.sum vendor/ && go mod tidy
Thanks to mundur for reporting this issue.
This is CVE-2026-56864 and Go issue https://go.dev/issue/80745.
- encoding/xml: add recursion depth guard during decode
Previously, DecodeElement would reset the depth counter
causing it to never fire; this could lead to stack
exhaustion.
This is CVE-2026-56859 and Go issue https://go.dev/issue/80481.
net/http: apply ReadHeaderTimeout when doing unencrypted HTTP/2 check
When a server is configured to support unencrypted HTTP/2, it reads a
few bytes from each new connection to see if they contain the HTTP/2
client preface. Previously, this was being done with no timeout applied.
ReadHeaderTimeout is now applied for this.
This is CVE-2026-56853 and Go issue https://go.dev/issue/80205.
- net/url: avoid quadratic complexity in resolvePath
Previously, resolving relative paths containing parent directory (..) segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead.
Now, path resolution operates on a byte buffer using index-based backtracking for .. segments, eliminating the quadratic time complexity and significantly reducing memory allocations.
This is CVE-2026-56860 and Go issue https://go.dev/issue/80494.
- golang.org/x/net/dns/dnsmessage: panic when parsing invalid SVCB record
Parsing an invalid SVCB or HTTPS RR can panic when
the size of a parameter value overflows the message buffer.
Thanks to Mundur (https://github.com/M0nd0R) for reporting this issue.
This is CVE-2026-46600 and Go issue https://go.dev/issue/79795.
- crypto/tls: limit handshake messages we are willing to accept post-handshake
Previously, we always counted handshake messages, such as KeyUpdate, as
state-advancing, regardless of whether a handshake has been completed or
not. As a result, a malicious client can keep sending KeyUpdate messages
to force the server to keep performing key derivation operations
indefinitely.
Thanks to Qi Deng of Aurascape.ai for reporting this issue.
This is CVE-2026-56862 and Go issue https://go.dev/issue/80528.
- html/template: fix Javascript regexp context tracking
Previously, pathological inputs could close an
unescaped / early, allowing for attack-controlled
data to inject arbitrary content, potentially
leading to XSS.
Thanks to Ali Sherif for reporting this issue.
This is CVE-2026-56858 and Go issue https://go.dev/issue/80435.
- x/net/idna: failure to reject ASCII-only Punycode-encoded labels
The ToASCII and ToUnicode functions incorrectly accepted Punycode-encoded labels
that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com")
incorrectly returned the name "example.com" rather than an error.
The idna package implements the processing algorithm from UTS 46.
Older versions of UTS 46 included a specification bug which permitted
multiple ASCII labels to decode to the same Unicode label.
UTS 46 revision 33 fixed the specification bug.
The idna package now implements the updated specification.
This behavior can lead to privilege escalation in programs using the idna package.
For example, a program which performs privilege checks on the ASCII hostname
may reject "example.com" but permit "xn--example-.com". If that program subsequently
converts the ASCII hostname to Unicode, it will inadvertently permits access
to the Unicode name "example.com".
Thanks to KC1zs4 (https://github.com/KC1zs4) for reporting this issue.
This is CVE-2026-39821 and Go issue https://go.dev/issue/78760.
- encoding/asn1: enforce maximum recursion depth
Enforce a recursion limit in Unmarshal to prevent stack exhaustion
when parsing deeply-nested, recursive structures.
Thanks to Marwan Atia (marwans...@gmail.com) for reporting this issue.
This is CVE-2026-33818 and Go issue https://go.dev/issue/80405.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Windows pull requests did not stress-test new or modified integration
tests, so Windows-specific flakes could reach the regular test suite.
Add a standalone workflow that detects selected tests before starting
costly build work, then runs each test 10 times on Windows 2025. Start
dockerd with the containerd runtime and snapshotter backend so the check
covers the latest supported Windows configuration.
Share test detection and `/flaky-check=TestA,TestB` parsing with the
existing Linux flaky-test path so both platforms select tests with the
same rules.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Paweł Gronowski