CVE-2025-47291

Executive Summary

CVE-2025-47291 is a vulnerability in the containerd container runtime, specifically within its CRI (Container Runtime Interface) implementation. The flaw, present in versions 2.0.1 through 2.0.4, causes containerd to fail to place usernamespaced containers under the correct Kubernetes cgroup hierarchy. This omission means that certain Kubernetes resource limits (e.g., CPU, memory) are not enforced for these containers, potentially allowing a single container to consume excessive node resources and cause a denial of service (DoS) of the entire Kubernetes node. The vulnerability has been patched in containerd 2.0.5 and 2.1.0. A temporary workaround is to disable usernamespaced pods in Kubernetes.

Supply Chain & Package Security

This vulnerability affects the containerd runtime, which is a core component of the Kubernetes ecosystem. Containerd is typically distributed as a binary or via package managers (e.g., apt, yum) and is often included in container images for Kubernetes nodes. The supply chain risk is moderate, as the vulnerability is in the runtime itself, not in a package registry. However, organizations using containerd 2.0.x must ensure their node images and deployment pipelines are updated to the patched version.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder or unassigned. Based on the vulnerability description, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Local (L) - The attacker must have the ability to run a container on the node.
• Attack Complexity (AC): Low (L) - No special conditions are required.
• Privileges Required (PR): Low (L) - The attacker needs the ability to create a usernamespaced pod.
• User Interaction (UI): None (N) - No user interaction is required.
• Scope (S): Unchanged (U) - The vulnerability affects the same node.
• Confidentiality (C): None (N) - No data confidentiality impact.
• Integrity (I): None (N) - No data integrity impact.
• Availability (A): High (H) - The vulnerability can cause a denial of service.

Estimated CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H Estimated Base Score: 5.5 (Medium)

Threat Level: Medium. The vulnerability requires local access to run a container, but it can lead to a significant availability impact on the Kubernetes node.

Deep Dive & Mechanics

The vulnerability lies in containerd's CRI implementation, which is responsible for integrating with Kubernetes. When a pod is created with user namespace support (userns), containerd is supposed to place the container's cgroups under the Kubernetes pod cgroup hierarchy (e.g., /sys/fs/cgroup/kubepods/...). This ensures that Kubernetes resource limits (CPU shares, memory limits, etc.) are applied.

In the affected versions, containerd fails to do this for usernamespaced containers. Instead, the container's cgroups are placed outside the Kubernetes hierarchy, meaning the limits set by Kubernetes are not enforced. An attacker who can create a usernamespaced pod can then run a container that consumes all available CPU, memory, or other resources on the node, causing a denial of service for other pods and potentially the node itself.

The root cause is a missing or incorrect cgroup path calculation when user namespaces are enabled. The fix in containerd 2.0.5 ensures that the cgroup hierarchy is correctly set for usernamespaced containers.

Vulnerable vs. Patched Code

The specific code change is not publicly available in the provided data, but based on the advisory, the fix involves correcting the cgroup path assignment for usernamespaced containers.

Vulnerable Code (Conceptual):

// In containerd's CRI implementation, when creating a container with userns:
if container.UsernsMode != "" {
    // Missing or incorrect cgroup path assignment
    // Container cgroups are placed outside the Kubernetes hierarchy
    cgroupPath = "/kubepods/besteffort/pod<uid>/<container-id>" // Incorrect or missing
}

Patched Code (Conceptual):

// In containerd 2.0.5+:
if container.UsernsMode != "" {
    // Correctly place cgroups under the Kubernetes pod hierarchy
    cgroupPath = "/kubepods/besteffort/pod<uid>/<container-id>" // Correctly assigned
}

The exact diff is not available, but the fix ensures that the cgroup path is properly constructed and applied for usernamespaced containers.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to a Kubernetes cluster running containerd 2.0.1 - 2.0.4.
• Ability to create pods with user namespace support (requires Kubernetes 1.25+ with UserNamespacesSupport feature gate).

Exploitation Steps:

1. Create a pod with user namespace support and no resource limits (or very high limits).
2. Inside the container, run a resource exhaustion attack (e.g., fork bomb, memory allocation).
3. Observe that the container is not constrained by Kubernetes limits, causing node instability.

Example Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  name: exploit-pod
spec:
  hostUsers: true  # Enable user namespace
  containers:
  - name: exploit
    image: busybox
    command: ["sh", "-c", "while true; do :; done"]  # CPU exhaustion
    resources:
      limits:
        cpu: "100m"  # This limit will NOT be enforced

Expected Outcome: The container will consume all available CPU, causing other pods to starve and potentially crashing the node.

Blue Team

Detection:

• Monitor for pods with hostUsers: true that are consuming excessive resources.
• Use cgroup monitoring to detect containers not under the expected Kubernetes hierarchy.

Mitigation:

• Apply the workaround: disable usernamespaced pods in Kubernetes by setting the UserNamespacesSupport feature gate to false.
• Update containerd to version 2.0.5 or later.

Hunting:

• Check for containers with cgroup paths that do not start with /kubepods/.
• Look for pods with hostUsers: true that have no resource limits or are exceeding limits.

Indicators of Compromise (IOCs)

• Cgroup Path Anomaly: Containers with cgroup paths outside the /kubepods/ hierarchy.
• Resource Exhaustion: Unusual CPU or memory usage on a node, especially from a single container.
• Pod Configuration: Pods with hostUsers: true and no resource limits.
• Containerd Version: Containerd version 2.0.1, 2.0.2, 2.0.3, or 2.0.4.

Detection Engineering

YARA Rule

rule CVE_2025_47291_Containerd_Cgroup_Bypass {
    meta:
        description = "Detect containerd versions vulnerable to CVE-2025-47291"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-47291"
    strings:
        $v1 = "containerd 2.0.1" nocase
        $v2 = "containerd 2.0.2" nocase
        $v3 = "containerd 2.0.3" nocase
        $v4 = "containerd 2.0.4" nocase
    condition:
        any of ($v*)
}

Sigma Rule

title: Containerd Cgroup Bypass for Usernamespaced Containers
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects containers with cgroup paths outside the Kubernetes hierarchy, indicating potential exploitation of CVE-2025-47291.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-47291
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: "cgroup"
        path|startswith: "/kubepods/"
    condition: not selection
falsepositives:
    - Containers running outside Kubernetes (e.g., standalone Docker)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-47291 Containerd Cgroup Bypass Attempt"; flow:to_server; content:"hostUsers"; nocase; content:"true"; nocase; distance:0; within:100; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update Containerd: Upgrade to containerd 2.0.5+ or 2.1.0+.
2. Workaround: If immediate update is not possible, disable usernamespaced pods in Kubernetes by setting the UserNamespacesSupport feature gate to false.

Long-Term Actions:

• Implement cgroup monitoring to detect anomalies.
• Enforce resource limits on all pods, including usernamespaced ones.
• Regularly update container runtime components.

Patch Details:

• Fixed in containerd 2.0.5 and 2.1.0.
• No official patch commit is provided in the advisory, but users should update to these versions.

Report generated by Valters IT DevSecOps & CTI Division