
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 2.0.0, < 2.0.13
Patched in 2.0.13
Vulnerable: <= 1.7.35
Patched in 1.7.36
Vulnerable: >= 2.1.0, < 2.2.9
Patched in 2.2.9
Vulnerable: >= 2.3.0, < 2.3.6
Patched in 2.3.6
Vulnerable: = 2.4.0
Patched in 2.4.1
Details
A vulnerability exists in containerd's image pull handlers where a crafted OCI image index containing deeply nested or heavily fanned-out descriptor graphs can cause unbounded CPU and memory consumption. During the PullImage operation, the recursive traversal and processing of child descriptors lack sufficient depth and breadth limits, and fail to adequately deduplicate identical descriptors. This unbounded traversal leads to excessive resource allocation.
Consequently, pulling a malicious image reference can result in prolonged stalls during container creation and significant resource pressure on the host system. This issue occurs entirely during the image pull phase, prior to any container execution.
This bug has been fixed in containerd 2.4.1, 2.3.6, 2.2.9, 2.0.13, and 1.7.36. Users should update to these versions to resolve the issue.
There are no known workarounds for this issue. Users are advised to only pull trusted images from known registries until the patch can be applied.
The containerd project would like to thank Jakub Ciolek at ElevenLabs and @jlgore who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
If you have any questions or comments about this advisory:
To report a security issue in containerd:
EPSS, exploit probability
Low0.36%
estimated chance of real-world exploitation in the next 30 days, higher than 29.6% of every CVE FIRST.org scores
Refreshed 11/9/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.