CVE-2025-62596: 
Rust vulnerability analysis and mitigation

CVE-2025-62596 is a container escape and denial-of-service vulnerability in youki, a container runtime written in Rust, caused by insufficiently strict write-target validation in its AppArmor handling combined with a shared-mount race condition during path resolution. It affects youki versions 0.5.6 and below (all versions prior to 0.5.7). The vulnerability was disclosed on November 5, 2025, as part of a coordinated release alongside a related runc advisory (GHSA-cgrx-mc8f-2prm). It carries a CVSS v4 score of 7.3 (High) (Github Advisory, youki Advisory).

The root cause is a combination of two weaknesses: CWE-61 (UNIX Symbolic Link Following) and CWE-363 (Race Condition Enabling Link Following). youki's AppArmor label-writing code only verifies that the write destination resides somewhere under procfs, but does not validate the specific target file. This means a write intended for /proc/self/attr/apparmor/exec can be redirected to any other procfs path (e.g., /proc/sys/kernel/hostname) that also satisfies the weak check. The redirection is achieved via a shared-mount race: while youki resolves a path component-by-component, a racing container with shared mounts can substitute intermediate path components, redirecting the final write target to an unintended procfs location. The core logic mirrors the vulnerability found in runc (GHSA-cgrx-mc8f-2prm), and the youki maintainers confirmed the issue after it was identified in runc (Github Advisory, runc Advisory).

Successful exploitation allows a low-privileged attacker to redirect youki's procfs writes to unintended kernel-controlled files, enabling unauthorized modification of critical system parameters. This can result in bypassing AppArmor LSM labels (causing container processes to run unconfined), writing to dangerous procfs files such as /proc/sysrq-trigger (causing host system crashes or hangs), or modifying /proc/sys/kernel/core_pattern to achieve container escape with full host root privileges. Both the container runtime system and the underlying host system are affected, with high integrity and availability impact on both, making this a significant container breakout risk (Github Advisory, runc Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires low privileges, local access, and active user interaction (e.g., triggering a container build with shared mounts), and also depends on a timing-sensitive race condition (attack requirements: present). The EPSS score is approximately 0.055% (17th percentile), indicating a low near-term exploitation probability. The runc advisory notes that exploit templates for this class of race attack using docker buildx build were identified by researchers (runc Advisory).

1. Prerequisite: Obtain low-privileged access to a system running youki version 0.5.6 or earlier, with the ability to launch containers that share mounts with other containers (e.g., via docker buildx build with custom shared mount configurations).
2. Set up racing containers: Configure two containers sharing a mount namespace or bind mount such that one container can manipulate the intermediate path components of /proc/self/attr/apparmor/exec during youki's path resolution.
3. Trigger path substitution race: While youki resolves the AppArmor label path component-by-component, use the racing container to substitute an intermediate directory (e.g., via a symlink in a tmpfs or a bind-mount swap) so that the final resolved path points to a different procfs file (e.g., /proc/sys/kernel/hostname, /proc/sysrq-trigger, or /proc/sys/kernel/core_pattern).
4. Exploit weak validation: youki's write-target check only verifies the destination is under procfs, so the redirected write passes validation and proceeds to the attacker-chosen procfs file.
5. Achieve impact: Depending on the redirected target — bypass AppArmor confinement (write to a no-op procfs file), crash the host (write AppArmor profile name docker-default to /proc/sysrq-trigger), or escape the container (write a malicious coredump handler path to /proc/sys/kernel/core_pattern) (runc Advisory, Github Advisory).

• Process: Unexpected child processes spawned from the youki container runtime process; container processes running without expected AppArmor confinement labels.
• Logs: Kernel logs (dmesg) showing unexpected sysrq events or coredump handler changes; container runtime logs showing AppArmor label write operations to unexpected procfs paths.
• File System: Unexpected changes to /proc/sys/kernel/core_pattern or /proc/sys/kernel/hostname; symlinks or bind-mounts appearing in container-accessible tmpfs directories pointing to procfs paths.
• Network: Unexpected outbound connections from container processes that should be confined by AppArmor, potentially indicating a container escape has occurred.

The primary remediation is to upgrade youki to version 0.5.7 or later, which replaces the vulnerable path resolution logic with a safe procfs API using the libpathrs library (Rust crate pathrs = "0.2.1"), ensuring writes are validated against the specific intended procfs inode rather than just the procfs filesystem (youki Advisory, Patch Commit). As interim mitigations: use rootless containers (which limit the privileges of the youki process itself, reducing the impact of misdirected writes); avoid running untrusted container images; and restrict low-privileged user access to container runtime environments. Monitoring and auditing procfs write operations can help detect exploitation attempts.

The vulnerability was disclosed as part of a coordinated multi-runtime security release on November 5, 2025, covering runc, youki, and crun. Aleksa Sarai (@cyphar from SUSE), who conducted the original research into this class of procfs write redirect attacks, was credited as the remediation developer for youki. The runc advisory notes that this class of attack had been discussed publicly at conferences as "future work" prior to disclosure, indicating awareness in the container security research community. Red Hat also tracked the vulnerability (Red Hat CVE).