CVE-2026-41579: 
cAdvisor Schwachstellenanalyse und -minderung

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. When setting up the container rootfs, the setupPtmx and setupDevSymlinks functions use os.Remove and os.Symlink with filepath.Join-constructed paths, which can be manipulated if the container image contains /dev as a symlink. Affected versions include runc prior to 1.3.6, 1.4.0 through 1.4.2, and 1.5.0-rc.1 through 1.5.0-rc.2. The vulnerability was first reported on June 13, 2026, and publicly disclosed on June 22, 2026. It carries a CVSS v3.1 base score of 3.3 (Low) and a CVSS v4.0 base score of 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 initialization code. The setupPtmx and setupDevSymlinks functions operate on host paths constructed via filepath.Join(rootfs, ...) before pivot_root(2) is called, meaning a container image that places a symlink at /dev pointing to an arbitrary host directory can cause runc to perform file operations (deletion or symlink creation) outside the container's intended filesystem scope. The fix, implemented in commit 864db8042dbb, refactors these codepaths to be fd-based using UnlinkInRoot and SymlinkInRoot, which safely scope all operations within the container rootfs file descriptor. Docker is not affected because it creates a top-level read-only overlay layer that masks any malicious /dev symlink before runc processes the image; however, Podman and containerd (which do not implement this masking) remain exposed (Github Advisory, Fix Commit).

Successful exploitation allows an attacker with control over a container image to cause runc to delete a host file named ptmx in an arbitrary pre-existing directory, or to create a hardcoded set of symlinks (core → /proc/kcore, fd → /proc/self/fd/, ptmx → pts/ptmx, stdin → /proc/self/fd/0, stdout → /proc/self/fd/1, stderr → /proc/self/fd/2) in that directory. There is no confidentiality impact, and availability impact is limited — notably, /dev/pts/ptmx cannot be unlinked by devpts regardless of privileges, and /dev/ptmx itself is protected by a symlink loop detection. The primary risk is host filesystem integrity pollution, with a theoretical (but difficult to achieve in practice) path to service disruption if critical host files are affected (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., /tmp/target or another pre-existing directory on the host).
2. Distribute or supply the image: Make the malicious image available to a victim using Podman or containerd (not Docker) backed by a vulnerable version of runc (< 1.3.6, 1.4.0–1.4.2, or 1.5.0-rc.1–rc.2).
3. Trigger container startup: Convince the victim (user interaction required) to pull and run the malicious image using a vulnerable runtime. When runc calls setupPtmx or setupDevSymlinks during rootfs initialization, it resolves the /dev symlink and operates on the host path.
4. Achieve host filesystem manipulation: Runc deletes any file named ptmx in the target host directory, and/or creates the hardcoded set of symlinks (core, fd, ptmx, stdin, stdout, stderr) with fixed targets in that directory, polluting the host filesystem (Github Advisory, runc Security Advisory).

• File System: Unexpected symlinks named core, fd, ptmx, stdin, stdout, or stderr appearing in host directories outside of /dev; unexpected deletion of a file named ptmx in a host directory.
• Logs: Container runtime logs (Podman or containerd) showing errors or unusual activity during rootfs setup for a newly pulled or run image; runc error messages related to /dev symlink resolution.
• Process: runc process performing unlink or symlink syscalls targeting paths outside the expected container rootfs during container initialization (Github Advisory).

Update runc to version 1.3.6, 1.4.3, or 1.5.0-rc.3 (or later stable releases), which replace the vulnerable path-based file operations with fd-based equivalents that safely scope all operations within the container rootfs. Docker users are not affected and do not require immediate action. As a workaround, enabling user namespaces restricts the attack to 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 also limit the scope of affected host paths, though their effectiveness has not been fully analyzed by the maintainers (Github Advisory, runc Security Advisory).

The runc maintainers (notably Aleksa Sarai / cyphar) chose to release the fix publicly without an embargo, citing the limited practical exploitability of the vulnerability. The advisory explicitly notes that Docker users are unaffected, while Podman and containerd users are exposed. The issue was independently reported by multiple researchers including "Davias", Arthur Chan (Ada Logics), Junyi Liu, and Derek Manzella, indicating broad community attention. Brief social media discussion was observed on Bluesky and Mastodon shortly after disclosure, and the issue was picked up by vulnerability tracking services including OSV, Vulners, and ENISA's EUVD (runc Security Advisory).