Containerd users must patch high-severity privilege escalation flaw
A flaw in containerd allows containers restored from checkpoints to bypass security policies and run with root privileges.
Key points
- Containerd versions 2.1.0 through 2.2.6 and 2.3.0 through 2.3.3 are vulnerable.
- The flaw allows bypassing security contexts during container restoration from untrusted checkpoints.
- Patches are available in versions 2.2.7 and 2.3.4, which disable the risky feature by default.
Organizations running containerd on Linux systems face a high-severity vulnerability that allows privilege escalation. The flaw exists in the CRI implementation and affects versions 2.1.0 up to 2.2.6 and 2.3.0 up to 2.3.3. Patches have been released in versions 2.2.7 and 2.3.4. Users of these older versions must update immediately to prevent potential security breaches.
How it unfolded
- GitHub advisory GHSA-p7v4-vr35-mj6f details the vulnerability in containerd's CRI implementation.
- The issue allows containers restored from untrusted checkpoints to bypass destination security contexts.
- Patches in versions 2.2.7 and 2.3.4 disable checkpoint restore via CreateContainer by default.
Who is affected
This issue impacts Linux systems running containerd with CRI checkpoint restore enabled. Users who do not utilize CRI checkpoint restore are not affected by this vulnerability. The flaw allows an attacker who can run a container with a crafted checkpoint image to execute processes as root. These processes gain full capabilities and no enforced seccomp filters, despite restrictive security policies requested by the orchestrator.
Our take on the response
The vendor has addressed the bug by disabling the problematic feature by default in patched versions. Users who rely on restore via the CreateContainer API can re-enable the feature, but this leaves the vulnerability present. The vendor notes that containerd cannot enforce destination security policy during CRIU process restoration. Users should stop and delete any containers restored from untrusted checkpoints.
Who needs to act first
Managed service providers should prioritize updating systems that expose container creation to untrusted users or external inputs. Teams usually begin by isolating production environments that utilize checkpoint restoration features. Before applying updates, administrators should back up current configurations and test the patch in a staging environment. If immediate patching is not feasible, restrict permissions for container creation to trusted internal accounts only. Monitor logs for unexpected privilege changes.
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, delete, and recreate any running containers that were restored from untrusted checkpoints.
- Restrict container creation permissions to trusted users if you cannot patch immediately.
- Validate container image sources to ensure they are from trusted providers before restoration.
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of containerd are vulnerable to CVE-2026-95837?
Versions 2.1.0 up to 2.2.6 and 2.3.0 up to 2.3.3 are vulnerable.
Is there a workaround for users who cannot patch immediately?
Users should restrict container creation permissions to trusted users and validate container image sources.
Does this vulnerability affect all containerd users?
No, it only affects Linux systems running containerd with CRI checkpoint restore enabled.
