CVE-2025-47291 is a medium-severity vulnerability affecting containerd, an open-source container runtime widely used in Kubernetes environments. The issue lies in containerd's Container Runtime Interface (CRI) implementation in versions starting from 2.0.1 up to but not including 2.0.5. Specifically, containerd fails to place usernamespaced containers under the Kubernetes cgroup hierarchy. Cgroups (control groups) are Linux kernel features used to limit, account for, and isolate resource usage (CPU, memory, disk I/O, network) of process groups. Kubernetes relies on cgroups to enforce resource limits and quality of service for pods and containers. Because usernamespaced containers are not correctly placed within the Kubernetes cgroup hierarchy, the resource limits configured in Kubernetes may not be enforced for these containers. This misconfiguration can lead to resource exhaustion on the Kubernetes node, potentially causing a denial of service (DoS) condition by allowing containers to consume excessive CPU or memory resources unchecked. The vulnerability does not require authentication or user interaction to be exploited, but it requires local access to deploy usernamespaced containers using the affected containerd versions. The issue has been fixed in containerd versions 2.0.5 and later, including 2.1.0+. As a temporary workaround, disabling usernamespaced pods in Kubernetes can mitigate the risk until an upgrade is performed. No known exploits are reported in the wild as of the publication date. The CVSS 4.0 score is 4.6 (medium severity), reflecting the local attack vector, low complexity, no privileges required, and a high impact on availability due to potential DoS. The vulnerability is classified under CWE-266 (Incorrect Privilege Assignment), indicating improper enforcement of resource control privileges in container runtime management.

For European organizations relying on Kubernetes clusters with containerd versions between 2.0.1 and 2.0.5, this vulnerability poses a risk of denial of service on Kubernetes nodes. This can disrupt critical business applications and services running in containerized environments, leading to downtime and potential loss of productivity. Organizations with multi-tenant Kubernetes clusters or those running resource-intensive workloads are particularly at risk, as malicious or misconfigured containers could consume excessive resources, affecting other tenants or services. The impact extends to cloud service providers and enterprises using container orchestration for microservices, CI/CD pipelines, and edge computing. Given the widespread adoption of Kubernetes and containerd in Europe’s digital infrastructure, including financial services, manufacturing, and public sector, the risk of operational disruption is significant. However, since exploitation requires local access and no remote exploit is known, the threat is somewhat contained to insiders or compromised nodes. Still, the inability to enforce resource limits undermines Kubernetes’ security and operational guarantees, potentially leading to cascading failures in critical systems.

1. Immediate upgrade of containerd to version 2.0.5 or later (including 2.1.0+) is the most effective mitigation to ensure proper cgroup enforcement for usernamespaced containers. 2. As a temporary measure, disable usernamespaced pods in Kubernetes to prevent deployment of containers that bypass cgroup limits. This can be done by adjusting Kubernetes feature gates or runtime configurations. 3. Implement strict access controls and monitoring on Kubernetes nodes to prevent unauthorized deployment of containers, limiting local access to trusted administrators only. 4. Monitor resource usage on Kubernetes nodes closely to detect abnormal spikes that may indicate exploitation attempts or misbehaving containers. 5. Employ runtime security tools that can enforce resource limits independently of containerd’s cgroup placement, providing an additional layer of defense. 6. Review and audit Kubernetes cluster configurations and container runtime versions regularly to ensure compliance with security best practices and timely patching. 7. Educate DevOps and security teams about this vulnerability and the importance of container runtime updates and resource limit enforcement.