29.6.1.1
Release date |
Name |
Upstream release |
|---|---|---|
2026-SEP-08 |
MCR 29.6.1.1 |
Moby 29.6.1 and Docker CLI 29.6.1 |
Important
Due to the upgrade of containerd from 1.x to 2.x, before you upgrade from a
previous MCR major release to MCR 29.6.1.1 you must upgrade
containerd.io before you upgrade docker-ee. In the event that you
have upgraded both components at the same time and some of the containers
that should have restarted remain stopped, you can get them running again by
restarting MCR with the systemctl restart docker command.
Changelog
MCR 29.6.1.1 is a maintenance release that rebuilds MCR 29.6.1 against the go1.26.6-m1 Fipster toolchain, updates containerd to 2.3.4, and picks up dependency updates in the engine. There are no functional changes and no upstream Moby or Docker CLI version change.
Security
MCR 29.6.1.1 release mitigates several CVEs that affect MCR container images. Click the dropdown link below for comprehensive details.
CVEs mitigated
CVE |
Image mitigated |
Problem details from upstream |
|---|---|---|
|
Handshake messages, such as KeyUpdate, are always considered 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. |
|
|
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. |
|
|
Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion. |
|
|
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. ReadHeaderTimeout is unexpectedly not being applied when doing this. |
|
|
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.2, ensureLinkPath in content/file/utils.go:262-275 validates a hardlink target relative to the extract base but returns the unresolved target, causing os.Link(“victim.secret”, “<extract_base>/payload.tar.gz/evil_cwd_link”) to resolve header.Linkname against the process current working directory for a Typeflag=TypeLink entry such as Name=payload.tar.gz/evil_cwd_link and Linkname=”victim.secret” with io.deis.oras.content.unpack: “true”, which can expose or tamper with files such as .env, .git/config, .aws/credentials, and ~/.ssh/config. This issue is fixed in version 2.6.2. |
|
|
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, registry/remote/repository.go in blobStore.completePushAfterInitialPost follows a registry-controlled Location header during monolithic blob upload and reuses the Authorization header from the initial POST request for the subsequent PUT request, allowing a malicious registry to return a cross-host Location and receive the caller’s credentials at an attacker-controlled endpoint. This issue is fixed in version 2.6.1. |
|
|
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, auth.Client follows the realm URL from a registry’s WWW-Authenticate: *** without validating the scheme or host, allowing a malicious or compromised registry to cause SSRF to internal networks such as http://169.254.169.254/, http://10.0.0.x/, and http://127.0.0.1/, or to downgrade a registry contacted over https:// to an http:// token endpoint in registry/remote/auth/client.go through Client.Do(), Client.fetchBearerToken(), fetchDistributionToken, and fetchOAuth2Token. This issue is fixed in version 2.6.1. |
|
|
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer. |
|
|
OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.15.0 to 1.42.0, the fix for CVE-2026-24051 changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms. This vulnerability is fixed in 1.43.0. |
|
|
The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode(“xn–example-.com”) incorrectly returns the name “example.com” rather than an error. 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”. |
|
|
Enforce a recursion limit in Unmarshal to prevent stack exhaustion when parsing deeply-nested, recursive structures. |
|
|
gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 :path pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, “deny” rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback “allow” rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx); AND that have a security policy contains specific “deny” rules for canonical paths but allows other requests by default (a fallback “allow” rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: Use a validating interceptor (recommended mitigation); infrastructure-level normalization; and/or policy hardening. |
|
|
OpenTelemetry-Go is the Go implementation of OpenTelemetry. From 1.36.0 to 1.40.0, multi-value baggage: header extraction parses each header field-value independently and aggregates members across values. This allows an attacker to amplify cpu and allocations by sending many baggage: header lines, even when each individual value is within the 8192-byte per-value parse limit. This vulnerability is fixed in 1.41.0. |
|
|
OpenTelemetry-Go is the Go implementation of OpenTelemetry. The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. A fix was released with v1.40.0. |
|
|
The tar extraction routines in moby/go-archive (Unpack, UnpackLayer, Untar/UntarUncompressed, and the ApplyLayer helpers) do not confine filesystem operations to the destination directory. The extractor decides where each archive entry lands using lexical string checks and then performs the filesystem operation on a path that is resolved by the OS, so links introduced by the archive can be followed out of the destination directory. An attacker who controls the contents of an archive can create or overwrite files at arbitrary paths writable by the extracting process. |
GitHub milestones
The GitHub milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 29.6 release.
Major component versions
Note
MCR component versions are referenced from the latest builds in the
test-29.6.1.0 branch pool (Ubuntu 24.04 / noble, amd64).
Release-candidate (rc) and technology-preview (tp) suffixes have
been stripped.
Version detail for the major components that comprise MCR 29.6.1 is presented in the table below:
Component |
Upstream Version |
Mirantis Version |
|---|---|---|
29.6.1m2 |
||
29.6.1m1 |
||
2.3.4m1 |
||
1.4.3m1 |
||
– |
||
– |
||
0.35.1-m.1 |
||
Fipster (Go runtime) |
– |
|
0.31.1 (vendored in Moby 29.6.1) |
– |
|
3.0.2m1 |
||
gVisor |
– |
|
Docker Compose CLI plugin |
5.1.4 |
5.1.4m1 |
OpenSSL (Mirantis FIPS, libcrypto3-mirantis, FIPS variant only) |
3.5.7 |
3.5.7 |
Platform test detail
Platform |
Kernel tested |
|---|---|
Oracle Linux 9.8 |
5.14.0-687.42.1.el9_8.x86_64 |
Oracle Linux 8.10 |
4.18.0-553.158.1.el8_10.x86_64 |
RHEL 10.0 |
6.12.0-211.49.1.el10_2.x86_64 |
RHEL 9.7 |
5.14.0-611.55.1.el9_7.x86_64 |
RHEL 9.6 |
5.14.0-570.132.1.el9_6.x86_64 |
RHEL 8.10 |
4.18.0-553.146.1.el8_10.x86_64 |
Rocky 10.1 |
6.12.0-211.49.1.el10_2.x86_64 |
Rocky 9.7 |
5.14.0-611.5.1.el9_7.x86_64 |
Rocky 8.10 |
4.18.0-553.137.1.el8_10.x86_64 |
Ubuntu 24.04 |
7.0.0-1011-aws |
Ubuntu 22.04 |
6.8.0-1063-aws |
Windows 2022 Core |
10.0 20348 |