A flaw was found in runc. This attack is a more sophisticated variant of CVE-2019-16884, which was a flaw that allowed an attacker to trick runc into writing the LSM process labels for a container process into a dummy tmpfs file and thus not apply the correct LSM labels to the container process. The mitigation applied for CVE-2019-16884 was fairly limited and effectively only caused runc to verify that when we write LSM labels that those labels are actual procfs files.

A flaw was found in runc. CVE-2025-52565 is very similar in concept and application toCVE-2025-31133, except that it exploits a flaw in /dev/console bind-mounts. When creating the /dev/console bind-mount (to /dev/pts/$n), if an attacker replaces /dev/pts/$n with a symlink then runc will bind-mount the symlink target over /dev/console.

A flaw was found in runc. This flaw exploits an issue with how masked paths are implementedin runc. When masking files, runc will bind-mount the container's /dev/null inode on top of the file. However, if an attacker can replace /dev/null with a symlink to some other procfs file, runc will instead bind-mount the symlink target read-write.

Due to the low severity of this CVE, this security patch is being released with NO embargo period.

[ Summary ]

runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with os.MkdirAll. While this can be used to create empty files, existing files will not be truncated.

An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed.

This is exploitable using runc directly as well as through Docker and Kubernetes.

The CVSS score for this vulnerability is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).

[ Workarounds ]

Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use /etc/sub[ug]id), this in practice means that an attacker would only be able to create inodes in world-writable directories.

A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though we haven't thoroughly tested to what extent the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack.

[ Patches ]

I've attached patches that apply cleanly for runc 1.1.13 and HEAD. We have also released runc 1.1.14 and 1.2.0-rc3 which contain these patches, so if you upgrade there is no need to apply these patches.

CVE-2024-45310.patch applies cleanly on top of runc HEAD[1]. If you are backporting the patch to apply on top of 1.2.0-rc2, you will need to also apply [2] at least. 1.1-.patch apply cleanly on top of 1.1.13.

[ Credit ]

Thanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from Microsoft for discovering and reporting this vulnerability.

[ References ]

The GitHub security advisory for this issue will be visible here[3] once it has become public.

[1]: 346b818dad833a5ae8ab55d670b716dadd45950e at time of writing. [2]: https://github.com/opencontainers/runc/pull/4359 [3]: https://github.com/opencontainers/runc/security/advisories/GHSA-jfvp-7x6p-h2pv

-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>

It was discovered that runC incorrectly checked mount targets. An attacker with a malicious container image could possibly mount over the /proc directory and escalate privileges. This issue only affected Ubuntu 18.04 LTS. (CVE-2019-16884) It was discovered that runC incorrectly performed access control. An attacker could possibly use this issue to escalate privileges. (CVE-2019-19921)

[[ Patch CRD: 2019-02-11 15:00 CET ]] [[ Exploit Code CRD: 2019-02-18 15:00 CET ]]

Hello,

I am one of the maintainers of runc (the underlying container runtime underneath Docker, cri-o, containerd, Kubernetes, and so on). We recently had a vulnerability reported which we have verified and have a patch for.

The researchers who found this vulnerability are: Adam Iwaniuk Borys Popławski

In addition, Aleksa Sarai (me) discovered that LXC was also vulnerable to a more convoluted version of this flaw.

== OVERVIEW ==

The vulnerability allows a malicious container to (with minimal user interaction) overwrite the host runc binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn't matter if the command is not attacker-controlled) as root within a container in either of these contexts:

Creating a new container using an attacker-controlled image. Attaching (docker exec) into an existing container which the attacker had previous write access to.

This vulnerability is not blocked by the default AppArmor policy, nor by the default SELinux policy on Fedora[++] (because container processes appear to be running as containerruntimet). However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace).

Our CVSSv3 vector is (with a score of 7.2):

AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H

The assigned CVE for this issue is CVE-2019-5736.

[++]: This is only the case for the "moby-engine" package on Fedora. The "docker" package as well as podman are protected against this exploit because they run container processes as containert.

== PATCHES ==

I have attached the relevant patch which fixes this issue. This patch is based on HEAD, but the code in libcontainer/nsenter/ changes so infrequently that it should apply cleanly to any old version of the runc codebase you are dealing with.

Please note that the patch I have pushed to runc master[1] is a modified version of this patch -- even though it is functionally identical (though we would recommend using the upstream one if you haven't patched using the attached one already).

== NON-ESSENTIAL EXPLOIT CODE ==

Several vendors have asked for exploit code to ensure that the patches actually solve the issue. Due to the severity of the issue (especially for public cloud vendors), we decided to provide the attached exploit code. This exploit code was written by me, and is more generic than the original exploit code provided by the researchers and works against LXC (it could likely be used on other vulnerable runtimes with no significant modification). Details on how to use the exploit code are provided in the README.

As per OpenWall rules, this exploit code will be published publicly 7 days after the CRD (which is 2019-02-18). If you have a container runtime, please verify that you are not vulnerable to this issue beforehand.

== IMPACT ON OTHER PROJECTS ==

It should be noted that upon further investigation I've discovered that LXC has a similar vulnerability, and they have also pushed a similar patch[2] which we co-developed. LXC is a bit harder to exploit, but the same fundamental flaw exists.

After some discussion with the systemd-nspawn folks, it appears that they aren't vulnerable (because their method of attaching to a container uses a different method to LXC and runc).

I have been contacted by folks from Apache Mesos who said they were also vulnerable (I believe just using the exploit code that will be provided). It is quite likely that most container runtimes are vulnerable to this flaw, unless they took very strange mitigations before-hand.

== OTHER NEWS ==

We have set up an announcement list for future security vulnerabilities, and you can see the process for joining here[3] (it's based on the Kubernetes security-announce mailing list). Please join if you distribute any container runtimes that depend on runc (or other OCI projects).

[1]: https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b [2]: https://github.com/lxc/lxc/commit/6400238d08cdf1ca20d49bafb85f4e224348bf9d [3]: https://github.com/opencontainers/org/blob/master/security.md

-- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>

runc has a vulnerability in the usage of system file descriptors that allows for container escape and access to the host filesystem. An attacker can exploit this by convincing users to run malicious or modified containers on their systems.