containerd EUVD-2026-97822

Exploitation requires that a victim host PULL or IMPORT an attacker-controlled image layer containing certain opaque whiteout configurations (interleaved files plus repeated .wh..wh..opq markers) processed by containerd's layer unpack handler in pkg/archive/tar.go. It is therefore gated by operator/pipeline action (UI:A) and a local vector (AV:L) - the attacker cannot trigger it remotely without the victim choosing to fetch the image. Limiting factors: only availability is affected (transient CPU consumption and slower/less concurrent image pulls, no code execution or data exposure); environments restricted to trusted, signed images from controlled registries are effectively not exposed; and affected deployments are those running containerd prior to 1.7.35, 2.0.12, 2.2.8, or 2.3.5.

This is a genuine-but-low-priority denial-of-service issue (CVSS 4.0 base 4.6, Medium), not a high-severity emergency. The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:N/VA:L) tells a consistent story: the only impact is limited availability (VA:L) with no confidentiality or integrity effect, and crucially the vector is LOCAL with required user/operator interaction (UI:A) - the malicious layer only does damage when something on the host pulls or imports the crafted image. This is CWE-400 resource exhaustion (redundant directory walks during opaque-whiteout processing), so the realistic worst case is wasted CPU, delayed container startup, and reduced image-pull concurrency, not compromise. No EPSS score was supplied, the CVE is NOT in CISA KEV, and no public exploit was provided (the GitHub 'source code evidence' is the upstream FIX commit plus a benchmark/regression test, which is remediation code, not weaponized PoC). Signals are therefore aligned and unalarming: no active-exploitation signal, no privilege escalation, no data impact. The main reason to patch promptly is that containerd is ubiquitous and the fix is trivial to adopt, so the effort/risk tradeoff favors updating even though real-world danger is modest. One caveat to verify: UI:A/AV:L assumes an operator (or automated pipeline) pulls an untrusted image - environments that only run vetted, signed images from trusted registries face negligible exposure.

An attacker publishes a container image to a registry (or supplies it to a build/CI pipeline) whose layer contains many files interleaved with repeated opaque whiteout markers (.wh..wh..opq). When an operator or automated system on the victim host pulls or imports that image, containerd's layer-unpack handler performs redundant, repeated directory traversals, burning CPU and delaying container startup and concurrent pulls for unrelated workloads. No public exploit code was provided, though the upstream fix commit and its benchmark illustrate the triggering tar structure.