runc is a CLI tool for spawning and running containers according to the OCI specification. In versions prior to 1.3.6, 1.4.0-rc.1, 1.4.0-rc.12, 1.5.0-rc.1, and 1.5.0-rc.1, when setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory. This issue is not exploitable under Docker, because Docker creates a top-level read-only layer that masks any malicious /dev symlink present in the container image — unlike some other Linux container tooling, whose higher-level runtimes built on runc remain exposed to exploitation via a malicious image. This issue has been fixed in versions 1.3.6, 1.4.3 and 1.5.0.
runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.
runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.
CVE-2025-31133 is a vulnerability in the runc container runtime tool where insufficient verification of the source of bind-mounts for /dev/null allows attackers to exploit symbolic link following. This flaw enables arbitrary mount gadget attacks that can lead to host information disclosure, denial of service, container escape, or bypassing of maskedPaths protections. The issue affects specific versions of runc prior to 1.2.8, between 1.3.0-rc.1 and before 1.3.3, and certain 1.4.0 release candidates. It has a high severity rating and a CVSS 4.0 score of 7.3. Fixes are available in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.
CVE-2023-27561 is a high-severity vulnerability in runc (up to version 1.1.4) caused by incorrect access control in the libcontainer/rootfs_linux.go component. It allows an attacker with limited privileges to escalate their privileges by spawning two containers with custom volume-mount configurations and running custom images. This issue is a regression of a previous vulnerability (CVE-2019-19921). Exploitation requires local access with the ability to create containers and does not require user interaction. The vulnerability impacts confidentiality, integrity, and availability, potentially allowing full system compromise. No known exploits are currently in the wild, but the risk remains significant for containerized environments. European organizations using vulnerable runc versions in container orchestration platforms should prioritize patching and restrict container creation permissions.