CVE-2025-47291

What it actually does

The containerd CRI implementation fails to place usernamespaced containers into the expected Kubernetes cgroup hierarchy, allowing resource limits defined by the cluster to be bypassed.

Why it matters to the business

A single compromised or malicious workload can exhaust node resources, causing denial of service for the entire Kubernetes node and disrupting all workloads running on it; the issue affects widely used containerd versions across many clusters.

How an attack unfolds

An attacker with the ability to schedule containers runs a usernamespaced pod that is not placed under the Kubernetes cgroup hierarchy; the pod then consumes CPU, memory, or I/O beyond its declared limits until the node becomes unresponsive.

How to fix it

Upgrade containerd to commit fb4c30d4ede3531652d86197bf3fc9515e5276d9 or later; for Ubuntu packages also apply the listed QEMU fixes where applicable (1:9.0.2+ds-4ubuntu2 for 24.10, 1:6.2+dfsg-2ubuntu6.27 for 22.04 LTS, 1:8.2.2+ds-0ubuntu1.10 for 24.04 LTS).

How to confirm the fix worked

Verify the running containerd binary or package version matches or exceeds the fixed commits listed; confirm that usernamespaced containers appear under the expected Kubernetes cgroup paths after upgrade.

Typical attack path

1. Gain access to deploy or influence container creation on a Kubernetes cluster using containerd
2. Create a usernamespaced container or pod with intentionally high resource consumption
3. Bypass applied Kubernetes limits because the container is outside the expected cgroup hierarchy
4. Exhaust node-level resources leading to node-level denial of service

How to detect it

Search container runtime logs and Kubernetes audit logs for creation of usernamespaced containers that later correlate with unexpected resource spikes or node NotReady events; review cgroup hierarchy under /sys/fs/cgroup for missing Kubernetes-managed subtrees associated with usernamespaced pods.

What your security team should do

• Immediately upgrade containerd to the fixed commit on all Kubernetes nodes
• Prioritize clusters with high node density or multi-tenant workloads
• Review and enforce pod security policies that restrict usernamespaced containers until patched
• Monitor for resource-exhaustion alerts on nodes until remediation is complete