CVE-2026-95838: containerd: Unpack DoS via repeated opaque whiteouts
Impact
A vulnerability exists in containerd's layer unpack handler where the processing of certain image layers causes superlinear time complexity. During the unpack operation, specific file configurations within the layer can trigger repeated directory traversals.
Consequently, pulling or importing a maliciously crafted image can result in increased unpack times and a moderate increase in CPU usage. This delays container startup, even if the compressed image layers are small. Additionally, in orchestrators like Kubernetes that apply concurrency limits to image pulls, these excessively long operations can reduce the available concurrency for other pulls, potentially delaying unrelated container deployments.
Patches
This bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.
Workarounds
There are no known workarounds for this issue. Users are advised to only pull and import trusted images from known registries until the patch can be applied.
Credits
The containerd project would like to thank Jakub Ciolek of AlphaSense 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
Other sources
containerd is an open-source container runtime. Prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5, containerd's layer unpack handler repeatedly traverses directories for certain opaque whiteout configurations. A malicious image layer can trigger repeated directory traversals while opaque whiteouts are processed. Pulling or importing the image can consume CPU, delay container startup, and reduce image-pull concurrency for unrelated deployments. This issue is fixed in versions 1.7.35, 2.0.12, 2.2.8, and 2.3.5.
— NVD
containerd: Unpack DoS via repeated opaque whiteouts
— Microsoft
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/containerd/containerd/v2to a version that resolves this vulnerability.Fixed in 2.3.5 - Upgrade
Upgrade
go/github.com/containerd/containerd/v2to a version that resolves this vulnerability.Fixed in 2.2.8 - Upgrade
Upgrade
go/github.com/containerd/containerdto a version that resolves this vulnerability.Fixed in 1.7.35 - Upgrade
Upgrade
go/github.com/containerd/containerd/v2to a version that resolves this vulnerability.Fixed in 2.0.12 - Upgrade
Upgrade
azurelinux/moby-containerd-ccto a version that resolves this vulnerability.Fixed in 1.7.7-19 - Upgrade
Upgrade
azurelinux/containerd2to a version that resolves this vulnerability.Fixed in 2.3.7-1 - Upgrade
Upgrade
azurelinux/kata-containersto a version that resolves this vulnerability.Fixed in 4.1.0.kata1-3 - Upgrade
Upgrade
azurelinux/kata-containers-ccto a version that resolves this vulnerability.Fixed in 3.15.0.aks0-24 - Upgrade
Upgrade
azurelinux/moby-engineto a version that resolves this vulnerability.Fixed in 25.0.18-2 - Upgrade
Upgrade
containerdto a version that resolves this vulnerability.Fixed in 2.3.5 - Compensating control
Only pull and import trusted images from known registries until the patch can be applied
Event History
Frequently Asked Questions
Which environments are exposed to this issue?
Environments running containerd versions earlier than 1.7.35, 2.0.12, 2.2.8, or 2.3.5 are affected when they pull or import a malicious image containing the relevant opaque whiteout layer configuration.
What does an attacker need to do to trigger the denial of service?
An attacker needs to provide a malicious container image layer configured with repeated opaque whiteouts and have that image pulled or imported. No privileges are required according to the supplied CVSS vector, but user interaction is required to initiate the pull or import.
What is the operational impact during exploitation?
Processing the malicious image can consume CPU through repeated directory traversals, delay container startup, and reduce image-pull concurrency for unrelated deployments.
What versions contain the fix?
Upgrade containerd to 1.7.35, 2.0.12, 2.2.8, or 2.3.5, as applicable to the release line in use.