CVE-2025-62596 is a critical (CVSS 10.0 in the record) flaw in youki, a container runtime written in Rust. Its AppArmor handling checks write targets too loosely, which allows writes to unintended procfs locations. The record lists 0.5.6 and below as affected and 0.5.7 as the fix.
What's affected
The NVD record states that youki versions 0.5.6 and below are affected and that the issue is fixed in 0.5.7. The weakness types are CWE-363 (race condition enabling link following) and CWE-61 (UNIX symbolic link following), both linked below.
Source conflict to note. The GitHub advisory (GHSA-vf95-55w6-qmrf) as rendered shows affected versions as 0.5.5 and below, with a patched version also given as 0.5.5, and it scores the issue High 7.3 under CVSS 4.0 with a local attack vector. NVD gives 10.0 under CVSS 3.1 with a network vector. Because the advisory text is internally inconsistent on versions, the safe move is to run 0.5.7 or later and check the advisory yourself.
How to check if you're exposed
Find out whether youki runs anywhere in your fleet. It is an alternative low level runtime, so it may be configured behind Docker, Podman or a Kubernetes node runtime. On a host:
youki --version
which youki
If you installed it with Cargo, list installed crates:
cargo install --list | grep youki
For Rust projects that depend on the youki libraries, check your lockfile:
cargo tree -i youki_lib 2>/dev/null; grep -n "youki" Cargo.lock
Also check your container engine and Kubernetes runtime class configuration for a youki entry. Many teams run it only on a few nodes or in test.
What to do now
- Inventory every host and node where youki is installed or configured as a runtime.
- Upgrade youki to 0.5.7 or later, then restart the container engine or node components that use it.
- Read the GitHub advisory GHSA-vf95-55w6-qmrf and the related runc advisory it references, GHSA-cgrx-mc8f-2prm, to confirm the fixed version for your build.
- Until patched, avoid running untrusted container images on youki hosts, and keep workloads on nodes that use a different runtime.
- Check whether you also run runc, and confirm it is on a release that includes the fix for the related runc issue.
Why it matters
A container runtime sets up the walls around a workload. If it can be tricked into writing to the wrong file in the host procfs, those walls are weaker. The advisory explains two parts. First, youki only verified that a write destination was somewhere under procfs, so a write meant for an AppArmor attribute file could land on a different procfs file. Second, while a path is resolved one component at a time, a race involving shared mounts can swap an intermediate component and redirect the final target.
The advisory says the core logic is similar to a CVE in runc, where the issues were found first and then confirmed in youki. It describes the outcome as container escape and denial of service. I did not find a statement of exploitation, and the record does not mark this CVE as CISA Known Exploited.
For teams with a software inventory, the useful question is where youki sits. Runtimes are easy to miss because they are not application dependencies.
Try it yourself
Runtimes and base images are part of what you ship. This demo walks through scanning a container image for known issues.
Click through it at your own pace, or open it full screen.
Quick check
Why do the record and the advisory disagree on severity?
NVD scores the issue 10.0 using CVSS 3.1 with a network vector, while the GitHub advisory uses CVSS 4.0 with a local vector and calls it High 7.3. Different scoring versions and assumptions produce different numbers. Patch either way.
Does this affect Docker or runc?
Not directly. The record is about youki. The advisory says similar issues were found in runc, so check the runc advisory it links if you run that runtime.
Sources
- Safeguard Gold entry for CVE-2025-62596
- youki advisory GHSA-vf95-55w6-qmrf
- CWE-363 on Gold
- CWE-61 on Gold
Last reviewed: 18 October 2026.
