Containers stack vulnerabilities · Page 2

Moby: Race condition in docker cp allows creation of arbitrary empty files on the host via symlink swap

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 create empty files or directories at arbitrary absolute paths on the host filesystem. This issue has been patched in Docker Engine version 29.5.1 and Moby Daemon version 2.0.0-beta.14.

• Update to 26.1.5+dfsg1-9+deb13u1
• Update to 28.5.2+dfsg4-3

Docker: `PUT /containers/{id}/archive` executes container binary on the host

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

• Update to 26.1.5+dfsg1-9+deb13u1
• Update to 28.5.2+dfsg4-3

ServiceAccount token disclosure via Azure IPAM CNI plugin logs

When Calico is configured with the Azure IPAM plugin, the Calico CNI binary mutates the incoming CNI configuration to attach subnet information before delegating to the IPAM plugin. After mutating, the Azure IPAM helper logs the entire unmarshaled configuration map (stdinData) at INFO level to /var/log/calico/cni/cni.log on every CNI ADD and DEL invocation — once per pod scheduled or terminated on the node. When the cluster is deployed using token-based Kubernetes authentication, this log entry contains the ServiceAccount token, client key, and certificate authority in plaintext. Any principal with read access to /var/log/calico/cni/cni.log o

• Update to 22.4.0
• Update to 3.21.7
• Update to 3.22.3
• Update to 3.32.0

Calicoctl leaks cluster credentials to stderr when verbose logging is enabled

When calicoctl is invoked with --log-level=info or --log-level=debug, the client prints the full contents of its loaded connection-configuration struct to stderr in a single log line. The struct embeds every credential calicoctl uses to talk to the cluster — inline kubeconfig (with bearer token), Kubernetes API bearer token, etcd password, and inline PEM-encoded etcd client certificate and key. Any reader of that stderr stream — CI job logs, session-recording archives, shared support-ticket transcripts, or local filesystem viewers on the host that ran calicoctl — can extract these credentials with zero Kubernetes privilege. calicoctl's defaul

• Update to 22.4.0
• Update to 3.21.7
• Update to 3.32.0

ServiceAccount token disclosure via install-cni container logs

In Calico, the install-cni init container logs the rendered CNI configuration to standard output. When the configuration template uses the __SERVICEACCOUNT_TOKEN__ placeholder (Canal/Flannel-Calico deployments), the installer substitutes the live Kubernetes ServiceAccount bearer token before logging, exposing the token to any authenticated user with pods/log permission in the namespace with calico-node. The token holds patch privileges on pods/status, enabling annotation-based attacks against cluster workloads. The default kubeconfig-based authentication path is not affected. This is a direct regression of TTA-2018-001.

• Update to 3.31.6

Moby: Off-by-one error in plugin privilege validation

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.

• Update to 26.1.5+dfsg1-9+deb13u1
• Update to 28.5.2+dfsg4-2

Moby: AuthZ plugin bypass with oversized request body

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.

• Update to 26.1.5+dfsg1-9+deb13u1
• Update to 28.5.2+dfsg4-2

ingress-nginx comment-based nginx configuration injection

A security issue was discovered in ingress-nginx where a combination of Ingress annotations can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

• Update to 1.13.9

ingress-nginx rewrite-target nginx configuration injection

A security issue was discovered in ingress-nginx where the `nginx.ingress.kubernetes.io/rewrite-target` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

• Update to 1.13.8

ingress-nginx auth-proxy-set-headers nginx configuration injection

A security issue was discovered in ingress-nginx where the `nginx.ingress.kubernetes.io/auth-proxy-set-headers` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

• Update to 1.12.5

cert-manager-controller DoS via Specially Crafted DNS Response

cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates. In versions from 1.18.0 to before 1.18.5 and from 1.19.0 to before 1.19.3, the cert-manager-controller performs DNS lookups during ACME DNS-01 processing (for zone discovery and propagation self-checks). By default, these lookups use standard unencrypted DNS. An attacker who can intercept and modify DNS traffic from the cert-manager-controller pod can insert a crafted entry into cert-manager's DNS cache. Accessing this entry will trigger a panic, resulting in denial‑of

ingress-nginx Admission Controller denial of service

A security issue was discovered in ingress-nginx where the validating admission controller feature is subject to a denial of service condition. By sending large requests to the validating admission controller, an attacker can cause memory consumption, which may result in the ingress-nginx controller pod being killed or the node running out of memory.

• Update to 1.13.7

ingress-nginx auth-url protection bypass

A security issue was discovered in ingress-nginx where the protection afforded by the `auth-url` Ingress annotation may not be effective in the presence of a specific misconfiguration. If the ingress-nginx controller is configured with a default custom-errors configuration that includes HTTP errors 401 or 403, and if the configured default custom-errors backend is defective and fails to respect the X-Code HTTP header, then an Ingress with the `auth-url` annotation may be accessed even when authentication fails. Note that the built-in custom-errors backend works correctly. To trigger this issue requires an administrator to specifically confi

• Update to 1.13.7

ingress-nginx auth-method nginx configuration injection

A security issue was discovered in ingress-nginx where the `rules.http.paths.path` Ingress field can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

• Update to 1.13.7

ingress-nginx auth-method nginx configuration injection

A security issue was discovered in ingress-nginx where the `nginx.ingress.kubernetes.io/auth-method` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller. (Note that in the default installation, the controller can access all Secrets cluster-wide.)

• Update to 1.13.7

Portworx Half-Blind SSRF in kube-controller-manager

A half-blind Server Side Request Forgery (SSRF) vulnerability exists in kube-controller-manager when using the in-tree Portworx StorageClass. This vulnerability allows authorized users to leak arbitrary information from unprotected endpoints in the control plane’s host network (including link-local or loopback services).

• Update to 1.20.5+really1.20.2-1

containerd CRI server: Host memory exhaustion through Attach goroutine leak

containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.

• Update to 1.2.6-0ubuntu1~16.04.6+esm6
• Update to 1.6.12-0ubuntu1~18.04.1+esm3
• Update to 1.6.12-0ubuntu1~20.04.8+esm1
• Update to 1.6.12-0ubuntu1~22.04.10
• Update to 1.6.20~ds1-1+deb12u3
• Update to 1.6.24~ds1-1ubuntu1.3+esm2
• Update to 1.7.24-0ubuntu1~20.04.2+esm1
• Update to 1.7.24~ds1-10
• Update to 1.7.24~ds1-6+deb13u1
• Update to 1.7.24~ds1-8ubuntu1.1
• Update to 1.7.28-0ubuntu1~22.04.1+esm1
• Update to 1.7.28-0ubuntu1~24.04.2
• Update to 2.1.3-0ubuntu3.1

runc: LSM labels can be bypassed with malicious config using dummy procfs files

runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the

• Update to 1.3.3+ds1-2
• Update to 1.3.3-0ubuntu1~22.04.2
• Update to 1.3.3-0ubuntu1~24.04.2
• Update to 1.3.3-0ubuntu1~25.10.2

container escape due to /dev/console mount and related races

runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured

• Update to 1.3.3+ds1-2
• Update to 1.3.3-0ubuntu1~22.04.2
• Update to 1.3.3-0ubuntu1~24.04.2
• Update to 1.3.3-0ubuntu1~25.10.2

runc container escape via "masked path" abuse due to mount race conditions

runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.

• Update to 1.3.3+ds1-2
• Update to 1.3.3-0ubuntu1~22.04.2
• Update to 1.3.3-0ubuntu1~24.04.2
• Update to 1.3.3-0ubuntu1~25.10.2