CVE-2025-47291: Containerd CRI DoS Vulnerability

CVE-2025-47291 Overview

CVE-2025-47291 is a vulnerability in containerd, the popular open-source container runtime. A bug was discovered in containerd's Container Runtime Interface (CRI) implementation where usernamespaced containers are not properly placed under the Kubernetes cgroup hierarchy. This misconfiguration causes certain Kubernetes resource limits to be ignored, potentially leading to a denial of service condition on the Kubernetes node.

Critical Impact

Kubernetes resource limits may not be enforced for usernamespaced pods, allowing containers to consume node resources without restriction and potentially causing node-level denial of service.

Affected Products

• containerd versions 2.0.1 through 2.0.4
• linuxfoundation containerd

Discovery Timeline

• 2025-05-21 - CVE-2025-47291 published to NVD
• 2025-09-19 - Last updated in NVD database

Technical Details for CVE-2025-47291

Vulnerability Analysis

This vulnerability stems from improper privilege management (CWE-266) in containerd's CRI implementation. When containerd creates usernamespaced containers, it fails to correctly position them within the Kubernetes cgroup hierarchy. Cgroups (control groups) are a Linux kernel feature that Kubernetes relies upon to enforce resource limits such as CPU, memory, and I/O constraints on pods and containers.

Under normal operation, Kubernetes sets resource limits through cgroup controllers, and the container runtime ensures these limits are applied to container processes. However, due to this bug, usernamespaced containers bypass this mechanism entirely, meaning they operate outside the expected resource constraint boundaries.

The vulnerability requires local access to exploit, as an attacker would need the ability to deploy pods with user namespace isolation enabled on the affected Kubernetes cluster. While no public exploits are currently available, the potential for resource exhaustion makes this a significant concern for multi-tenant Kubernetes environments.

Root Cause

The root cause is a logic error in containerd's CRI implementation where usernamespaced container processes are not correctly associated with the Kubernetes-managed cgroup hierarchy. When user namespaces are enabled for a container, the code path responsible for cgroup assignment fails to properly link the container's processes to the appropriate cgroup subtree that Kubernetes monitors and enforces limits on.

Attack Vector

The attack vector is local, requiring an attacker to have the ability to create and deploy pods on a Kubernetes cluster running a vulnerable version of containerd. The attack scenario involves:

1. An attacker deploys a pod configured to use user namespaces on a vulnerable Kubernetes node
2. The pod's containers are created outside the proper cgroup hierarchy
3. Kubernetes resource limits (CPU, memory, etc.) are not enforced on these containers
4. The attacker's containers can consume unlimited node resources, starving other workloads and potentially causing node instability or complete denial of service

For detailed technical information about the vulnerability mechanism and its exploitation, refer to the GitHub Security Advisory.

Detection Methods for CVE-2025-47291

Indicators of Compromise

• Pods using user namespaces with unexpectedly high resource consumption that exceeds their configured limits
• Kubernetes node resource exhaustion despite properly configured pod resource quotas
• Cgroup hierarchy showing usernamespaced containers outside the expected kubepods cgroup subtree
• Node-level OOM (Out of Memory) events occurring when pod limits should prevent such conditions

Detection Strategies

• Monitor containerd version across all Kubernetes nodes and flag any instances running versions 2.0.1 through 2.0.4
• Implement cgroup auditing to verify all container processes are correctly placed under the Kubernetes cgroup hierarchy
• Deploy node-level resource monitoring that compares actual container resource usage against configured Kubernetes limits
• Review kubelet logs for resource limit enforcement anomalies

Monitoring Recommendations

• Set up alerts for Kubernetes nodes experiencing unexpected resource pressure when pod limits appear adequate
• Monitor for discrepancies between pod resource specifications and actual resource consumption metrics
• Implement continuous compliance scanning to detect vulnerable containerd versions in your container infrastructure
• Use SentinelOne Singularity Platform to monitor container runtime behavior and detect anomalous resource consumption patterns

How to Mitigate CVE-2025-47291

Immediate Actions Required

• Upgrade containerd to version 2.0.5 or later, or 2.1.0 or later on all affected Kubernetes nodes
• Temporarily disable usernamespaced pods in Kubernetes clusters running vulnerable containerd versions
• Audit existing deployments to identify any pods currently using user namespaces
• Implement node resource monitoring to detect potential exploitation attempts before upgrading

Patch Information

The containerd maintainers have released fixed versions that properly place usernamespaced containers under the Kubernetes cgroup hierarchy:

• containerd 2.0.5+ - Fixes the cgroup hierarchy issue for the 2.0.x branch
• containerd 2.1.0+ - Includes the fix in the 2.1.x branch

Users should upgrade to these versions as soon as possible. For complete patch details and upgrade instructions, see the GitHub Security Advisory.

Workarounds

• Disable user namespace support in Kubernetes by setting hostUsers: true or removing user namespace configuration from pod specifications
• Implement admission controllers to block pods requesting user namespaces until the upgrade is complete
• Apply node-level resource limits as an additional layer of protection using kernel-level cgroup constraints
• Consider isolating workloads requiring user namespaces to dedicated nodes that can be prioritized for patching

# Configuration example
# Verify containerd version on Kubernetes nodes
containerd --version

# Check if usernamespaced pods are deployed (requires kubectl access)
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.hostUsers == false) | .metadata.name'

# Upgrade containerd (example for apt-based systems)
sudo apt-get update
sudo apt-get install containerd.io=2.0.5-1
sudo systemctl restart containerd