29.6.1
Release date |
Name |
Upstream release |
|---|---|---|
2026-AUG-04 |
MCR 29.6.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 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.
Highlights
Enhancement |
Detail |
|---|---|
gVisor |
gVisor is now available for general use. Due to a known upstream
issue, you must
create gVisor containers with a TTY ( |
Image attestations API |
The new |
Rootless network driver change |
|
Time namespaces are on by default |
Containers now run in a private time namespace by default on supported
kernels. The |
Windows daemon on a Unix socket |
On Windows, the daemon can now listen on a Unix socket ( |
Changelog
MCR 29.6.1 comprises the Moby 29.6.1 upstream release. In addition, changes are included for the interceding upstream 29.5.0, 29.5.1, 29.5.2, 29.5.3, and 29.6.0 versions, for which there were no MCR releases.
Changes specific to MCR
There are no MCR-specific changes in this release. All changes are inherited from the upstream Moby and Docker CLI releases described below.
Changes from upstream
MCR 29.6.1 includes all upstream changes from the Moby and Docker CLI 29.5.0 through 29.6.1 releases. The Highlights section above calls out the most significant changes. For the rest of the changes — smaller CLI and API additions and the full set of daemon, networking, and rootless mode bug fixes — refer to the upstream release notes and the GitHub milestones below.
Security
CVE |
Image mitigated |
Problem details from upstream |
|---|---|---|
|
containerd is an open-source container runtime. In Versions prior to 2.3.2, 2.2.5 and 2.1.9, the CRI implementation improperly trusts Container Device Interface (CDI) annotations found within untrusted checkpoint image metadata during container restoration. When restoring a container from a checkpoint, containerd preserves CDI-related annotations from the checkpoint archive rather than relying solely on the pod’s create-time specification. This allows a user with pod creation permissions to bypass standard Kubernetes resource allocation and device plugin enforcement, injecting arbitrary CDI edits (such as device nodes and host mounts) into the restored container. Successful exploitation requires that the node has CDI enabled and contains a matching host CDI specification for the requested device; environments where CDI is disabled or lacking sensitive device specifications are not affected. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9. |
|
|
containerd is an open-source container runtime. Versions prior to 2.3.2, 2.2.5 and 2.1.9 contain a bug where the CRI plugin restores container.log from a checkpoint image without validating a symlinked path. This could result in reading an arbitrary file on the host via kubectl logs. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9. |
|
|
containerd is an open-source container runtime. In versions prior to 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10 the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations. This issue has been fixed in versions 1.7.33, 2.3.2, 2.2.5, 2.1.9, and 2.0.10. |
|
|
containerd is an open-source container runtime. Versions prior to 2.3.2, 2.2.5 and 2.1.9 contain a vulnerability in the CRI checkpoint import process where it fails to validate the image references specified within a checkpoint image’s configuration. An attacker with permissions to create pods can use a crafted checkpoint image to force containerd to pull a malicious image and assign it an arbitrary local tag, thereby poisoning the node’s local image cache. Subsequently, if other pods on the same node attempt to use the poisoned tag with an IfNotPresent (or Never) pull policy, they will unknowingly execute the attacker’s malicious image instead of the legitimate one. This can lead to a compromise of the affected pods, allowing the attacker to execute arbitrary code under the victim pod’s identity. This issue has been fixed in versions 2.3.2, 2.2.5 and 2.1.9. |
|
|
||
|
containerd is an open-source container runtime. Versions prior to 1.7.33, 2.0.10, 2.1.9, 2.2.5 and 2.3.2, contain a vulnerability that allows a maliciously crafted image to cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the containerd process. This renders the container runtime API unavailable and can disrupt clients such as the Docker Engine or Kubernetes control-plane components. This issue has been fixed in versions 1.7.33, 2.0.10, 2.1.9, 2.2.5 and 2.3.2. |
|
|
containerd is an open-source container runtime. In versions prior to 1.7.32, 2.0.9, 2.2.4 and 2.3.1, containers launched with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username, leading to runAsNonRoot evasion. If a crafted image provides an /etc/passwd file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes runAsNonRoot restriction to be bypassed, causing unexpected behavior for environments that require containers to run as a non-root user. This issue has been fixed in versions 1.7.32, 2.0.9, 2.2.4 and 2.3.1. |
|
|
For certain crafted inputs, a ‘ed25519.PrivateKey’ was created by casting malformed wire bytes, leading to a panic when used. |
|
|
An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs. |
|
|
Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped. |
|
|
Previously, a revoked ‘SignatureKey’ belonging to a CA was not correctly checked for revocation. Now, both the ‘key’ and ‘key.SignatureKey’ are checked for @revoked. |
|
|
Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU. |
|
|
Moby is an open source container framework. In Docker Engine prior to version 29.5.1, Docker Daemon versions 28.5.2 and prior, and Moby Daemon prior to version 2.0.0-beta.14, a race condition during docker cp mount setup allows a malicious container to redirect a bind mount target to an arbitrary host path, potentially overwriting host files or causing denial of service. This issue has been patched in Docker Engine version 29.5.1 and Moby Daemon version 2.0.0-beta.14. |
|
|
Moby is an open source container framework. In versions prior to 29.5.1 and in moby/moby v2 prior to v2.0.0-beta.14, when a compressed archive is uploaded to a container via PUT /containers/{id}/archive or piped through docker cp -, the daemon resolves decompression binaries (such as xz or unpigz) from the container’s filesystem rather than the host’s due to incorrect ordering of operations. A malicious container image containing a trojanized decompression binary can achieve arbitrary code execution with full daemon privileges, including host root UID and unrestricted capabilities, when a user uploads a compressed (xz or gzip) archive into that container. This issue is fixed in Docker Engine 29.5.1 and moby/moby v2.0.0-beta.14. Workarounds include only running containers from trusted images, using authorization plugins to restrict access to the PUT /containers/{id}/archive endpoint, and avoiding piping compressed archives into containers created from untrusted images |
|
|
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 Dial and LookupPort functions panic on Windows when provided with an input containing a NUL (0). |
|
|
SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil. |
|
|
When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation. |
|
|
A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection’s read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded. |
|
|
The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2. |
|
|
When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error. |
|
|
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”. |
|
|
Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations. |
|
|
Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows attackers to bypass authorization plugins (AuthZ). This issue has been patched in version 29.3.1. |
|
|
Moby is an open source container framework. Prior to version 29.3.1, a security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon’s privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user. Plugins that request exactly one privilege are also affected, because no comparison is performed at all. This issue has been patched in version 29.3.1. |
|
|
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0. |
|
|
When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash. |
|
|
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. |
|
|
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, “.”) to execute repeatedly on the same input hostname. With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname’s label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates. |
|
|
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. |
Deprecated
Creation of a container on the default bridge network with
--linknow produces a deprecation warning.
GitHub milestones
The GitHub milestones offer full detail on the pull requests and changes as they correlate to the upstream Moby 29.5 and 29.6 releases.
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.1m1 |
||
29.6.1m1 |
||
2.2.6m1 |
||
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 |