CVE-2026-95838: 
Helm vulnerability analysis and mitigation

CVE-2026-95838 is a Denial of Service (DoS) vulnerability in containerd's layer unpack handler, caused by superlinear time complexity when processing certain opaque whiteout configurations in image layers. A malicious image layer can trigger repeated directory traversals during the unpack operation, consuming excessive CPU and memory resources. Affected versions include containerd prior to 1.7.35, 2.0.12, 2.2.8, and 2.3.5. The vulnerability was disclosed on September 4, 2026, and published to NVD on October 12, 2026. It carries a CVSS v4.0 base score of 4.6 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-407 (Inefficient Algorithmic Complexity). In the applyNaive function within pkg/archive/tar.go, encountering an opaque whiteout marker (.wh..wh..opq) triggers a full directory walk to remove files from lower layers. When a malicious image layer interleaves regular files and opaque whiteout markers within the same directory, each whiteout triggers a repeated walk over the same growing directory, resulting in O(n²) or worse execution time. Benchmark results from the fix commit show that with n=1,000 entries, execution time dropped from ~2,578 ms/op to ~135 ms/op (~19x improvement) and memory allocations fell by ~98.8% after the patch (GitHub Commit, GitHub Advisory). Exploitation requires user interaction (active pulling or importing of a malicious image), and no privileges are required on the attacker's side.

Successful exploitation causes increased unpack times and elevated CPU and memory usage on the host running containerd, delaying container startup even when the compressed image layers are small. In orchestrated environments such as Kubernetes, which apply concurrency limits to image pulls, the prolonged unpack operations reduce available concurrency for other image pulls, potentially delaying unrelated container deployments across the cluster. There is no confidentiality or integrity impact; the vulnerability is limited to availability (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the time of publication (Feedly). The EPSS score is 0.0, indicating very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to craft a malicious container image and have a victim pull or import it, limiting the attack surface to scenarios where untrusted images are consumed (GitHub Advisory).

1. Craft a malicious image layer: Create a tar archive that interleaves regular files and opaque whiteout markers (.wh..wh..opq) within the same directory. For example, alternate between writing a regular file entry (e.g., f0001) and an opaque whiteout entry for the same directory, repeating this pattern hundreds or thousands of times.
2. Package as a container image: Wrap the malicious tar layer into a valid OCI or Docker image manifest and push it to a registry accessible by the target.
3. Induce the victim to pull the image: Trick or wait for the target containerd host to pull or import the malicious image (e.g., via a Kubernetes pod spec referencing the attacker-controlled registry, or a CI/CD pipeline).
4. Trigger the DoS: When containerd's applyNaive function processes the layer, each opaque whiteout triggers a full directory walk over the growing directory, causing superlinear CPU and memory consumption that delays or stalls container startup and reduces image-pull concurrency for other workloads (GitHub Advisory, GitHub Commit).

• Process: Sustained high CPU usage by the containerd process (containerd, containerd-shim) during image pull or import operations, disproportionate to the size of the image being pulled.
• Logs: containerd logs showing abnormally long unpack durations for image layers; repeated or stalled image pull operations in orchestrator logs (e.g., Kubernetes kubelet logs showing image pull timeouts or delays).
• Network: Image pulls from unexpected or unknown registries, particularly registries not in the organization's approved list.
• File System: Presence of image layers containing a high density of .wh..wh..opq (opaque whiteout) entries interleaved with regular files, detectable by inspecting pulled image layer tarballs (GitHub Advisory).

Users should upgrade containerd to one of the patched versions: 1.7.35, 2.0.12, 2.2.8, or 2.3.5. There are no known configuration-based workarounds for this vulnerability. As an interim measure, the containerd project advises users to pull and import only trusted images from known, vetted registries until the patch can be applied (GitHub Advisory).

The vulnerability was responsibly disclosed by Jakub Ciolek of AlphaSense and credited by the containerd project. The advisory was published by maintainer Samuel Karp. No significant broader media coverage or notable community debate has been identified beyond standard CVE aggregator coverage (GitHub Advisory).