Ce mail provient de l'extérieur, restons vigilants ===================================================================== CERT-Renater Note d'Information No. 2026/VULN1048 _____________________________________________________________________ DATE : 19/10/2026 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running containerd/v2 (Go) versions prior to 2.2.10, 2.3.7, 2.4.2. ==================================================================== https://github.com/containerd/containerd/security/advisories/GHSA-8647-2jxj-p2rc https://github.com/containerd/containerd/security/advisories/GHSA-vwhp-8p66-mq4f https://github.com/containerd/containerd/security/advisories/GHSA-5p7c-hggf-c748 _____________________________________________________________________ containerd: daemon crash when pulling an image with a crafted Content-Length header Moderate samuelkarp published GHSA-8647-2jxj-p2rc Package github.com/containerd/containerd/v2 (Go) Affected versions >= 2.2.0, < 2.2.10, >= 2.3.0, < 2.3.7, >= 2.4.0, < 2.4.2 Patched versions 2.2.10, 2.3.7, 2.4.2 Description Impact A bug in containerd's image pull process can cause containerd to crash when downloading layers from an untrusted registry. When parallel layer fetch is enabled, an untrusted registry returning a crafted Content-Length header can trigger an unhandled memory allocation panic. This issue only affects configurations where concurrent_layer_fetch_buffer is set to enable parallel layer fetch; default configurations with this setting disabled are not affected. A daemon crash interrupts in-flight container operations and blocks new pod startup until containerd is restarted by a service manager, though existing running containers remain unaffected. Patches This bug has been fixed in containerd 2.4.2, 2.3.7, and 2.2.10. Users should update to these versions to resolve the issue. Workarounds Ensure concurrent_layer_fetch_buffer is set to 0 (the default) or omitted in containerd's configuration under [plugins."io.containerd.transfer.v1.local"] and [plugins."io.containerd.cri.v1.images"] to disable parallel layer fetch. Restrict pod image references to trusted registries (for example, using a Kubernetes ValidatingAdmissionPolicy or admission webhook). Credits The containerd project would like to thank Opensec Intelligence for responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at security@containerd.io To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io Severity Moderate CVE ID No known CVE Weaknesses Weakness CWE-20 Weakness CWE-400 Weakness CWE-770 Credits @Kushalkhemka Kushalkhemka Finder @mayank-jangid-moon mayank-jangid-moon Finder @skigeek16 skigeek16 Finder @opensec-intelligence opensec-intelligence Tool _____________________________________________________________________ containerd: daemon crash when processing an image manifest with a malformed digest Moderate samuelkarp published GHSA-vwhp-8p66-mq4f Package github.com/containerd/containerd/v2 (Go) Affected versions >= 2.2.0, < 2.2.10, >= 2.3.0, < 2.3.7, >= 2.4.0, < 2.4.2 Patched versions 2.2.10, 2.3.7, 2.4.2 Description Impact A bug in containerd's image manifest processing causes an unrecovered panic when a child descriptor contains the io.containerd.manifest.subject annotation and a malformed digest. Pulling or importing such an image through the transfer service (including default CRI PullImage requests) crashes the containerd daemon. In Kubernetes environments, kubelet retries failed image pulls with backoff, allowing a pod referencing an untrusted image to repeatedly crash containerd and disrupt container operations on the worker node. Patches This bug has been fixed in containerd 2.4.2, 2.3.7, and 2.2.10. Users should update to these versions to resolve the issue. Workarounds Restrict pod image references to trusted registries (for example, using a Kubernetes ValidatingAdmissionPolicy or admission webhook) and only pull or import images from trusted sources. Credits The containerd project would like to thank @melihgurlek, LEI WANG (@ssst0n3) and Haoyuan Zhang (@zj1ng7), and OpenSec Intelligence who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at security@containerd.io To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io Severity Moderate CVE ID CVE-2026-95839 Weaknesses No CWEs Credits @ssst0n3 ssst0n3 Finder @zj1ng7 zj1ng7 Finder @Kushalkhemka Kushalkhemka Finder @opensec-intelligence opensec-intelligence Tool @mayank-jangid-moon mayank-jangid-moon Finder @skigeek16 skigeek16 Finder @melihgurlek melihgurlek Finder _____________________________________________________________________ containerd CRI plugin: mount and snapshot leak when container checkpoint restore fails Moderate samuelkarp published GHSA-5p7c-hggf-c748 Package github.com/containerd/containerd/v2 (Go) Affected versions >= 2.2.0, < 2.2.10, >= 2.3.0, < 2.3.7 Patched versions 2.2.10, 2.3.7 Description Impact A bug in containerd's CRI plugin on Linux can cause containerd to leak read-only mounts and pinned snapshots when restoring a container from a checkpoint image fails. Repeatedly creating containers from a checkpoint image with malformed metadata or a base image that cannot be pulled can exhaust the host mount table and disk space indefinitely. In Kubernetes, this resource exhaustion can prevent containerd and the kubelet from pulling images or starting new pods on the node. Patches This bug has been fixed in containerd 2.3.7 and 2.2.10. Users should update to these versions to resolve the issue. To release resources from mounts leaked prior to the update, administrators must unmount any lingering /tmp/checkpoint* mount points on the host (or reboot the node) so containerd can garbage-collect the pinned snapshots. Workarounds containerd 2.4 does not support restore via the CRI plugin and is not vulnerable to this bug. In containerd 2.3 and 2.2, disable CRI checkpoint and restore support by setting enable_criu = false under [plugins."io.containerd.cri.v1.runtime"] (or [plugins."io.containerd.grpc.v1.cri"] in config version 2) in containerd's configuration, or ensure enable_experimental_restore_via_create is set to false (the default starting in containerd 2.3.4 and 2.2.7). Restrict pod image references to trusted registries (for example, using a Kubernetes ValidatingAdmissionPolicy or admission webhook). Credits The containerd project would like to thank @IamwhatIamSY for responsibly disclosing this issue in accordance with the containerd security policy. For more information If you have any questions or comments about this advisory: Open an issue in containerd Email us at security@containerd.io To report a security issue in containerd: Report a new vulnerability Email us at security@containerd.io Severity Moderate CVE ID No known CVE Weaknesses Weakness CWE-400 Weakness CWE-772 @IamwhatIamSY IamwhatIamSY Reporter ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================