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
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.
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.
-
Open the ModifyClusterNodePool API in the OpenAPI Portal.
-
Set the following parameters. Leave all others at their default values.
Parameter Value ClusterIdYour cluster ID NodepoolIdThe ID of the edge node pool to update runtime_version1.6.39 -
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
-
Mark the node as unschedulable. Replace
<NODE_NAME>with the actual node name.kubectl cordon <NODE_NAME> -
Evict all pods from the node.
kubectl drain <NODE_NAME> --grace-period=120 --ignore-daemonsets=true
Apply the fix
-
Log in to the target edge node.
-
Set the
REGIONandINTERCONNECT_MODEenvironment variables.Variable Description REGIONThe region ID where your cluster is located. For supported regions, see Supported regions. INTERCONNECT_MODEThe node's network connection type: basic(public network) orprivate(private network).export REGION="cn-hangzhou" INTERCONNECT_MODE="basic" # Replace with your actual values. -
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" -
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. -
Restrict to trusted images
-
Use the
ACKAllowedRepospolicy in security policy management to limit your cluster to images from trusted repositories. Apply the principle of least privilege to control who can import images. -
Use Notation and Ratify to sign and verify OCI artifacts to secure your container image supply chain.
-
-
Harden LSM policies
If you use AppArmor or SELinux, configure your security policies to cover critical system paths and restrict unnecessary access.
ImportantEven with such security policies in place, CVE-2025-52881 can still bypass some LSM protections. Upgrading the container runtime remains the most effective solution.