All Products
Search
Document Center

Container Service for Kubernetes:Remediation for runc vulnerabilities CVE-2025-31133,CVE-2025-52565,and CVE-2025-52881

Last Updated:Mar 26, 2026

Three high-severity runc vulnerabilities — CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 — allow container escapes by bypassing runc's write restrictions on the host's /proc directory. ACK Edge has patched all three in containerd 1.6.39. Upgrade as soon as possible.

Vulnerability description

All three CVEs exploit different flaws in runc but share the same end result: a full container escape by gaining write access to files in the host's /proc directory.

CVE-2025-31133 — flaw in maskedPaths implementation

An attacker can replace /dev/null inside the container with a symbolic link (symlink) pointing to a sensitive file in the host's /proc directory. This causes critical system files to be unintentionally mounted as writable, allowing an attacker to achieve a container escape. Additionally, if an attacker deletes /dev/null, runc's error-handling path can leak sensitive kernel information.

CVE-2025-52565 — path traversal in /dev/console bind mount

runc fails to validate the destination path when creating a bind mount for the container's /dev/console. An attacker can use path traversal to mount an arbitrary host file to /dev/console, then write to it freely — leading to a container escape.

CVE-2025-52881 — logic flaw in Linux Security Module (LSM) label assignment

A bug in how runc sets LSM labels — including AppArmor and SELinux — can cause security policies configured for a container to be applied incorrectly, weakening container isolation. This flaw could be combined with other vulnerabilities to increase the effectiveness of an attack.

For full technical details, see the runc security notices.

Impact scope

The following runc versions are affected:

Status Versions
Affected runc 1.2.7 and earlier, runc 1.3.2 and earlier, runc 1.4.0-rc.2 and earlier
Patched runc 1.2.8, runc 1.3.3, runc 1.4.0-rc.3

Solutions

ACK Edge has fixed all three vulnerabilities in containerd 1.6.39.

Cloud node pools

Refer to the containerd runtime release notes and upgrade your cluster's container runtime to a patched version. For step-by-step instructions, see Update a node pool.

Edge node pools

Important

This procedure applies only to edge node pools using containerd as the container runtime. If your edge node pool uses Docker, create a new edge node pool with containerd and migrate your nodes before proceeding.

Important

Remediate nodes in batches rather than all at once to maintain system stability.

Step 1: Update the node pool's runtime configuration

Updating the edge node pool configuration ensures that any new nodes provisioned later automatically use containerd 1.6.39.

  1. Open the ModifyClusterNodePool API in the OpenAPI Portal.

  2. Set the following parameters. Leave all others at their default values.

    Parameter Value
    ClusterId Your cluster ID
    NodepoolId The ID of the edge node pool to update
    runtime_version 1.6.39
  3. Submit the API call.

Step 2: Upgrade containerd on existing nodes

Repeat the following steps for each existing edge node in the pool.

Drain the node
  1. Mark the node as unschedulable. Replace <NODE_NAME> with the actual node name.

    kubectl cordon <NODE_NAME>
  2. Evict all pods from the node.

    kubectl drain <NODE_NAME> --grace-period=120 --ignore-daemonsets=true
Apply the fix
  1. Log in to the target edge node.

  2. Set the REGION and INTERCONNECT_MODE environment variables.

    Variable Description
    REGION The region ID where your cluster is located. For supported regions, see Supported regions.
    INTERCONNECT_MODE The node's network connection type: basic (public network) or private (private network).
    export REGION="cn-hangzhou"  INTERCONNECT_MODE="basic"  # Replace with your actual values.
  3. Run the remediation script.

    #!/bin/bash
    set -e -x
    
    # --- Parameter validation ---
    if [[ $REGION == "" ]];then
        echo "Error: REGION is null"
        exit 1
    fi
    
    if [[ $INTERCONNECT_MODE == "" ]]; then
       echo "Error: INTERCONNECT_MODE is null"
       exit 1
    fi
    
    # --- Check if upgrade is needed ---
    if containerd --version | grep -q "1.6.39"; then
       echo "No need to upgrade current containerd (1.6.39)"
       exit 0
    fi
    
    export OS_ARCH=amd64
    case $(uname -m) in
    "sw_64")
        export OS_ARCH=sw64
        ;;
    "x86_64")
        export OS_ARCH=amd64
        ;;
    "arm64")
        export OS_ARCH=arm64
        ;;
    "aarch64")
        export OS_ARCH=arm64
        ;;
    *)
        echo "Unknown architecture $(uname -a). Defaulting to amd64."
        ;;
    esac
    
    INTERNAL=$( [ "$INTERCONNECT_MODE" = "private" ] && echo "-internal" || echo "" )
    SERVER="http://aliacs-k8s-${REGION}.oss-${REGION}${INTERNAL}.aliyuncs.com"
    
    if grep -q -E "Ubuntu|Debian" /etc/os-release; then
        export PKG_MGR="-deb"
    else
        export PKG_MGR=""
    fi
    
    CONTAINERD_VERSION="1.6.39"
    CONTAINERD_PACKAGE_URL="$SERVER/public/pkg/containerd${PKG_MGR}/containerd${PKG_MGR}-${CONTAINERD_VERSION}-linux-${OS_ARCH}.tar.gz"
    
    # --- Download and install ---
    wget $CONTAINERD_PACKAGE_URL -O /tmp/containerd.tar.gz
    mkdir -p /tmp/containerd
    tar xf /tmp/containerd.tar.gz -C /tmp/containerd
    
    if [[ $PKG_MGR == "-deb" ]]; then
        apt install -y /tmp/containerd/pkg/containerd-deb/$CONTAINERD_VERSION/deb/*.deb
    else
        yum localinstall -y /tmp/containerd/pkg/containerd/$CONTAINERD_VERSION/rpm/*
    fi
    
    # --- Restart and confirm ---
    systemctl restart containerd
    echo "Successfully upgraded containerd"
  4. Check the output to confirm the result.

    • If the node was already running 1.6.39, the script exits with:

      No need to upgrade current containerd (1.6.39)
    • If the upgrade completed successfully:

      Successfully upgraded containerd
Restore the node

Make the node schedulable again. Replace <NODE_NAME> with the actual node name.

kubectl uncordon <NODE_NAME>

Workarounds if an upgrade is not possible

If you cannot upgrade immediately, the following measures reduce risk. None of these workarounds fully eliminates the vulnerabilities — upgrading the container runtime is the only complete fix.

  • Use rootless containers

    In rootless mode, runc runs as a non-root user with limited permissions. This can effectively mitigate most attacks that rely on malicious writes to the host's procfs.

    See Run a kubelet inside a user namespace.

  • Restrict to trusted images

  • Harden LSM policies

    If you use AppArmor or SELinux, configure your security policies to cover critical system paths and restrict unnecessary access.

    Important

    Even with such security policies in place, CVE-2025-52881 can still bypass some LSM protections. Upgrading the container runtime remains the most effective solution.