Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain CRI CreateContainer access
-
ExploitSupply crafted checkpoint for restore
-
ExecutionCRIU reinstates forged privileged state
-
ImpactRun as root with full caps, no seccomp
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Least privilege enforcement
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitable only on containerd 2.1.0 through pre-2.2.7 (the 2.2.x line) and 2.3.0 through pre-2.3.4, AND only when CRI checkpoint restore via CreateContainer is active - enabled by default before 2.3.4 but disabled by default afterward unless the operator sets enable_experimental_restore_via_create = true under [plugins."io.containerd.cri.v1.runtime"]. The attacker must be able to invoke CRI CreateContainer with an attacker-controlled checkpoint archive (i.e. hold orchestrator/kubelet or crictl create privileges), which per CVSS PR:L is an authenticated, privileged, local operation. Limiting factors: systems that never use CRI checkpoint restore are entirely unaffected, the feature is experimental and deprecated (removal targeted for v2.4), the vector is local rather than network, and the attacker needs the ability to supply the crafted checkpoint. |
| Impact | CVSS 7.8 (High) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H indicates a local, low-complexity, authenticated (PR:L) attack with high confidentiality, integrity and availability impact. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit was supplied, so exploitation status is: no public exploit identified at time of analysis. Practical risk is strongly gated: the description explicitly states systems not using CRI checkpoint restore are unaffected, and the PR diff shows this restore-via-CreateContainer path is deprecated and disabled by default from v2.3.4 onward, so only deployments that opted into checkpoint/restore (forensic checkpointing, live migration, CRIU workflows) are actually exposed. Where enabled, impact is severe: a crafted checkpoint yields a process running as root with full capabilities and no seccomp while CRI status falsely reports the requested hardened config, effectively a container-isolation and privilege-escalation bypass. Signal conflict to verify: the supplied CVSS uses S:U, but because restored privileges break container confinement and can affect the host, this is better modeled as a scope change (S:C) - see assessed vector. Net: not a mass-exploitation internet-facing emergency (local vector, requires CRI create access, niche feature), but a genuine priority for any environment using CRI checkpoint restore. |
| Exploit ScenarioDerived | An attacker who can create containers through the CRI (for example a tenant permitted to schedule pods or invoke crictl create in a cluster that uses checkpoint restore) supplies a crafted checkpoint image to CreateContainer. During restore, CRIU reinstates the process credentials, capabilities, no_new_privs and seccomp state from the checkpoint instead of enforcing the destination ContainerConfig, so the container runs as root with full capabilities and no seccomp filter while CRI status reports the requested configuration. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
Privilege escalation in containerd's CRI checkpoint-restore path allows an authenticated local attacker who can submit an attacker-controlled checkpoint archive via CRI CreateContainer to have the restored process run with restored credentials (including root), full capabilities, and restored no_new_privs and seccomp state, while CRI status continues to report the requested ContainerConfig. The flaw affects containerd 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3, and only where CRI checkpoint restore via CreateContainer is actually used; systems that never use this experimental feature are not affected. Rated CVSS 7.8 (High) with a local, low-complexity, authenticated (PR:L) vector, and no public exploit identified at time of analysis. Fixed in 2.2.7 and 2.3.4, where the restore-via-CreateContainer behavior is additionally disabled by default.
RemediationAI
Vendor-released patch: upgrade containerd to 2.2.7 or 2.3.4 (or later in the respective lines) as documented in advisory GHSA-p7v4-vr35-mj6f and the fix commit 928c03c. Starting in 2.3.4, restoring checkpoint data during CRI CreateContainer is disabled by default; do not set enable_experimental_restore_via_create = true under [plugins."io.containerd.cri.v1.runtime"] unless the workflow genuinely requires the deprecated behavior, and if it is enabled, treat every checkpoint archive as fully untrusted and never let unprivileged or untrusted principals supply one. The trade-off of leaving the setting disabled is that existing checkpoint-restore automation breaks and requires migration to the replacement RestorePod API per KEP-5823 (https://github.com/kubernetes/enhancements/issues/5823) before the deprecated path is removed in containerd v2.4. Forensic checkpoint generation remains available and enabled by default via enable_criu = true, so evidence-collection workflows are unaffected by the mitigation. As a compensating control where upgrading is not immediately possible, restrict the ability to invoke CRI CreateContainer with checkpoint restore to trusted kubelet/crictl-level principals (the same PR:L boundary the attacker must already cross), monitor for CreateContainer calls carrying restore/checkpoint parameters, and treat CRI-reported container configuration as untrusted for security auditing since it can diverge from the restored process's actual credentials, capabilities, no_new_privs, and seccomp state. No public exploit code was identified at time of analysis, and exploitation is limited to environments where the CRI checkpoint-restore path is active.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
containerd is a widely deployed open-source container runtime that backs Kubernetes through its CRI (Container Runtime Interface) plugin. The affected code path is the CRI CreateContainer checkpoint-restore workflow, which relies on CRIU (Checkpoint/Restore In Userspace) to reconstruct a previously checkpointed process tree. The root cause is CWE-269 (Improper Privilege Management): during restore, CRIU repopulates the process security state from the checkpoint image rather than reconciling it with - or enforcing - the destination container's ContainerConfig. As a result, credentials (UID/GID), Linux capabilities, the no_new_privs flag, and seccomp filter state are all attacker-controllable through the checkpoint archive, so a restored process can run as root with full capabilities and no seccomp confinement even though the orchestrator-visible configuration claims otherwise. The mismatch between actual runtime privileges and reported CRI status is significant because it defeats configuration-based auditing and admission expectations. The vulnerable CPE entry is cpe:2.3:a:containerd:containerd:*:*:*:*:*:*:*:*, and the feature itself is experimental and was deprecated in the 2.3 line, with removal targeted for v2.4 in favor of a dedicated RestorePod API tracked under KEP-5823. Note that the scope of the flaw crosses a privilege boundary (reflected as S:C in the independent assessment vector), since the restored process gains privileges beyond those the destination ContainerConfig would grant.
Know when Containerd gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
AV:L and PR:L because exploitation needs local, authenticated CRI CreateContainer access with a crafted checkpoint; S:C because restored privileges break container confinement and impact the host.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
containerd is an open-source container runtime. From 2.1.0 until 2.2.7 and 2.3.4, containerd's CRI CreateContainer checkpoint restore is vulnerable because CRIU restores process security state from checkpoint data instead of enforcing the destination ContainerConfig. An attacker who can create a container from a crafted checkpoint can supply restored credentials, capabilities, no_new_privs, and seccomp state. The restored process can run as root with full capabilities and no enforced seccomp filters while CRI status reports the requested configuration. Systems that do not use CRI checkpoint restore are not affected. This issue is fixed in versions 2.2.7 and 2.3.4.
Executive ViewAI
A high-severity privilege escalation vulnerability in containerd allows an authenticated local attacker to gain root-level access on hosts that use the experimental CRI checkpoint restore feature. Organizations running affected containerd versions (2.1.0-2.2.6 or 2.3.0-2.3.3) with this feature enabled face potential container escape and full host compromise, which could lead to lateral movement and data breaches. Leadership should prioritize remediation to protect critical container infrastructure and maintain trust with customers and regulators.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
More in Containerd
View allcontainerd is an open source container runtime. Rated high severity (CVSS 7.8), this vulnerability is low attack complex
containerd is a container runtime available as a daemon for Linux and Windows. Rated high severity (CVSS 7.5), this vuln
Denial of service in containerd versions prior to 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 allows an unauthenticated atta
Host command execution in containerd's CRI plugin arises because labels from an image config (Dockerfile LABEL instructi
Native code execution inside the shim zygote process is possible in runwasi's containerd-shim-wasmtime-v1 prior to 0.6.1
Kubernetes device-plugin and resource-allocation enforcement can be bypassed in containerd by a namespace user holding p
Arbitrary host file disclosure in containerd's CRI plugin lets an attacker read any file on the Kubernetes node via `kub
containerd is an open source container runtime with an emphasis on simplicity, robustness and portability. Rated high se
Integer overflow in containerd overlaybd's LSMT index loader (do_load_index) lets a crafted, untrusted overlaybd blob pu
containerd is an open source container runtime. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploit
containerd is a container runtime. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no auth
In containerd (an industry-standard container runtime) before versions 1.3.10 and 1.4.4, containers launched through con
EUVD-2026-97820
GHSA-p7v4-vr35-mj6f
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB