Key points
- Containerd versions 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3 are vulnerable to CVE-2026-95837.
- Patches are available in containerd 2.2.7 and 2.3.4, which disable the risky restore feature by default.
- The vulnerability affects Linux systems using CRI checkpoint restore; other users are not impacted.
Containerd versions 2.1.0 up to 2.2.6 and 2.3.0 up to 2.3.3 contain a high-severity vulnerability identified as CVE-2026-95837. According to the GitHub advisory GHSA-p7v4-vr35-mj6f, this flaw allows a container restored from an untrusted checkpoint to bypass security contexts. Fixes are available in containerd 2.2.7 and 2.3.4. Users of these patched versions have the problematic feature disabled by default.
In plain English
When restoring a container from a checkpoint archive or image, the system usually enforces security rules. In these vulnerable versions, the restoration process ignores those rules. It loads process credentials and capabilities directly from the checkpoint data instead. This means a malicious checkpoint can run as root with full capabilities. The system reports that security policies are active, even though they are not enforced.
The background
The issue stems from how containerd handles the Container Runtime Interface (CRI) checkpoint restore. It uses CRIU to restore process states. Rather than applying the destination container's security configuration, it trusts the source data. This allows an attacker with a crafted checkpoint image to execute processes with elevated privileges. The discrepancy is hidden from orchestrators because status reporting reflects the requested configuration, not the actual state.
What changes now
Developers have addressed the bug in containerd 2.2.7 and 2.3.4. These updates disable checkpoint restore via the `CreateContainer` API by default. The feature was removed entirely in containerd 2.4.0. Users who need this functionality can re-enable it using a new configuration option, but doing so leaves the vulnerability present. Running containers restored from untrusted checkpoints should be stopped and recreated.
Who needs to act first
Teams should prioritize updating systems that actively use checkpoint restore features. Start by identifying which servers run vulnerable containerd versions. Test the update in a non-production environment to ensure compatibility with existing workloads. Back up current configurations before applying changes. If immediate patching is not possible, restrict permissions for container creation to trusted users only. Monitor logs for unexpected privilege escalations or anomalous process behavior during the transition period.
What to do and how to stay safe: containerd
- Update containerd to version 2.2.7 or 2.3.4 to disable the vulnerable checkpoint restore feature by default.
- Stop and delete any containers that were restored from untrusted checkpoints, then recreate them.
- Restrict permissions for container creation to trusted users if you cannot patch immediately.
- Monitor system logs for signs of unauthorized privilege escalation or unexpected root processes.
Step-by-step guide: Out-of-Band Patches: Meaning, Risks, and Deployment Reality
General security guidance from the Patch Herald newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which containerd versions are affected by this vulnerability?
Versions 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3 are vulnerable.
Is there a fix available for this issue?
Yes, patches are available in containerd 2.2.7 and 2.3.4.
Can I keep using checkpoint restore after patching?
You can re-enable it, but the vulnerability remains if you do.
