CVE-2026-41579: 
cAdvisor 脆弱性の分析と軽減

CVE-2026-41579 is a UNIX symbolic link (symlink) following vulnerability in runc, the OCI-compliant container runtime, that allows a malicious container image to trigger limited host filesystem integrity violations. The vulnerability affects runc versions prior to 1.3.6, versions 1.4.0 through 1.4.2, and 1.5.0-rc.1 through 1.5.0-rc.2. It was initially reported by "Davias" and published on June 13, 2026, with the advisory formally released on June 22, 2026. The CVSS v3.1 base score is 3.3 (Low), while the CVSS v4.0 base score is 4.8 (Medium) (GitHub Advisory, runc Security Advisory).

The root cause is improper symlink resolution (CWE-61: UNIX Symbolic Link Following) in runc's container rootfs setup functions setupPtmx and setupDevSymlinks. These functions called os.Remove and os.Symlink using filepath.Join-constructed paths before pivot_root(2) is called, meaning a container image with /dev configured as a symlink could redirect these operations to host filesystem paths outside the container boundary. An attacker crafting a malicious image with /dev as a symlink can trick runc into either deleting a host file named ptmx or creating a hardcoded set of symlinks (e.g., core → /proc/kcore, fd → /proc/self/fd/, ptmx → pts/ptmx, stdin/stdout/stderr → /proc/self/fd/[0-2]) in an arbitrary pre-existing host directory. The fix (commit 864db8042dbb) refactored these codepaths to use fd-based operations (UnlinkInRoot and SymlinkInRoot) that are scoped within the container root file descriptor, preventing symlink escape (runc Security Advisory, Fix Commit).

Successful exploitation results in limited host filesystem integrity violations — specifically, deletion of a host file named ptmx (outside of the protected /dev/pts/ptmx and /dev/ptmx paths) or creation of a fixed set of symlinks in an arbitrary pre-existing host directory. There is no confidentiality or availability impact under normal conditions, though deletion of /dev/ptmx could theoretically disrupt terminal managers (e.g., tmux) and tools relying on glibc's terminal creation. The symlinks created are constrained to hardcoded names and targets pointing to /proc paths, significantly limiting the potential for privilege escalation or container breakout. Docker users are not affected due to Docker's top-level read-only layer masking malicious /dev symlinks; however, Podman and containerd users running runc are exposed (GitHub Advisory, runc Security Advisory).

1. Craft a malicious container image: Create a container image where /dev is replaced with a symbolic link pointing to a target host directory (e.g., a world-writable directory or a directory containing a file named ptmx).
2. Distribute the image: Publish the malicious image to a public or private container registry accessible to the target environment running Podman or containerd (not Docker) with a vulnerable runc version (< 1.3.6, 1.4.0–1.4.2, or 1.5.0-rc.1–rc.2).
3. Trigger container startup: Induce a user or automated pipeline to pull and run the malicious image. This is the required user interaction step.
4. Exploit symlink resolution: During rootfs setup, runc's setupPtmx calls os.Remove on filepath.Join(rootfs, "dev/ptmx") — because /dev is a symlink, this resolves to the attacker-controlled host path, deleting a file named ptmx there. Similarly, setupDevSymlinks calls os.Symlink to create the hardcoded set of symlinks in the resolved host directory.
5. Achieve impact: The attacker has now either deleted a host file named ptmx or polluted a host directory with symlinks (core, fd, ptmx, stdin, stdout, stderr) pointing to /proc paths, potentially disrupting services that parse those paths as configuration (runc Security Advisory, Fix Commit).

• File System: Unexpected symlinks named core, fd, ptmx, stdin, stdout, or stderr appearing in host directories outside of /dev, pointing to /proc/kcore, /proc/self/fd/, pts/ptmx, or /proc/self/fd/[0-2].
• File System: Missing file named ptmx in a host directory that previously contained one (outside of /dev/pts/ptmx and /dev/ptmx).
• Logs: Container runtime logs (Podman or containerd) showing errors or unusual behavior during rootfs setup for a newly pulled image, particularly around /dev initialization.
• Container Registry: Presence of a container image in the local image store where the /dev path resolves to a symbolic link rather than a directory — detectable via docker inspect or skopeo inspect on image layers.

Update runc to version 1.3.6, 1.4.3, or 1.5.0-rc.3 (or later stable releases 1.5.0+), which fix the vulnerability by switching /dev initialization to fd-based operations scoped within the container root (runc Security Advisory, Fix Commit). Docker users are not affected and do not require immediate action. As a workaround, enabling user namespaces restricts the attack so that the attacker can only affect directories writable by the remapped root user (typically only world-writable directories for rootless containers using /etc/sub[ug]id). SELinux (container_runtime_t label) or AppArmor rules for the host runc context may further limit the scope of affected host filesystem paths, though the runc team has not performed an in-depth analysis of LSM effectiveness against this specific issue.

The runc maintainer (Aleksa Sarai / cyphar) published the advisory without an embargo, citing the significantly limited practical impact of the vulnerability and the presence of multiple mitigating factors. The issue was credited to four independent reporters: "Davias" (initial finder), Arthur Chan from Ada Logics, Junyi Liu, and Derek Manzella, indicating broad researcher attention to runc's rootfs handling. The advisory notes a related issue in crun was published around the same time, suggesting coordinated research into container runtime symlink handling. Community discussion appeared on oss-security mailing lists and social platforms (Bluesky, Mastodon) shortly after disclosure (runc Security Advisory).