Impact
In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b").
Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R vectors, despite attacks 2 and 3b requiring far more minimal user interaction (just reasonable runc exec operations on a container the attacker has access to). In any case, all four attacks can lead to full control of the host system.
Attack 1: process.cwd "mis-configuration"
In runc 1.1.11 and earlier, several file descriptors were inadvertently leaked internally within runc into runc init, including a handle to the host's /sys/fs/cgroup (this leak was added in v1.0.0-rc93). If the container was configured to have process.cwd set to /proc/self/fd/7/ (the actual fd can change depending on file opening order in runc), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem. This alone is not an exploit against runc, however a malicious image could make any innocuous-looking non-/ path a symlink to /proc/self/fd/7/ and thus trick a user into starting a container whose binary has access to the host filesystem.
Furthermore, prior to runc 1.1.12, runc also did not verify that the final working directory was inside the container's mount namespace after calling chdir(2) (as we have already joined the container namespace, it was incorrectly assumed there would be no way to chdir outside the container after pivotroot(2)).
The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (8.2, high severity).
Note that this attack requires a privileged user to be tricked into running a malicious container image. It should be noted that when using higher-level runtimes (such as Docker or Kubernetes), this exploit can be considered critical as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using ONBUILD in the case of Docker).
Attack 2: runc exec container breakout
(This is a modification of attack 1, constructed to allow for a process inside a container to break out.)
The same fd leak and lack of verification of the working directory in attack 1 also apply to runc exec. If a malicious process inside the container knows that some administrative process will call runc exec with the --cwd argument and a given path, in most cases they can replace that path with a symlink to /proc/self/fd/7/. Once the container process has executed the container binary, PRSETDUMPABLE protections no longer apply and the attacker can open /proc/$execpid/cwd to get access to the host filesystem.
runc exec defaults to a cwd of / (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use --cwd and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the execve will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the runc exec is executing).
The CVSS score for this attack is CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N (7.2, high severity).
Attacks 3a and 3b: process.args host binary overwrite attack
(These are modifications of attacks 1 and 2, constructed to overwrite a host binary by using execve to bring a magic-link reference into the container.)
Attacks 1 and 2 can be adapted to overwrite a host binary by using a path like /proc/self/fd/7/../../../bin/bash as the process.args binary argument, causing a host binary to be executed by a container process. The /proc/$pid/exe handle can then be used to overwrite the host binary, as seen in CVE-2019-5736 (note that the same #! trick can be used to avoid detection as an attacker). As the overwritten binary could be something like /bin/bash, as soon as a privileged user executes the target binary on the host, the attacker can pivot to gain full access to the host.
For the purposes of CVSS scoring:
Attack 3a is attack 1 but adapted to overwrite a host binary, where a malicious image is set up to execute /proc/self/fd/7/../../../bin/bash and run a shell script that overwrites /proc/self/exe, overwriting the host copy of /bin/bash. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6, high severity). Attack 3b is attack 2 but adapted to overwrite a host binary, where the malicious container process overwrites all of the possible runc exec target binaries inside the container (such as /bin/bash) such that a host target binary is executed and then the container process opens /proc/$pid/exe to get access to the host binary and overwrite it. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H (8.2, high severity).
As mentioned in attack 1, while 3b is scored lower it is more dangerous in practice as it doesn't require a user to run a malicious image.
Patches runc 1.1.12 has been released, and includes patches for this issue. Note that there are four separate fixes applied:
Checking that the working directory is actually inside the container by checking whether os.Getwd returns ENOENT (Linux provides a way of detecting if cwd is outside the current namespace root). This explicitly blocks runc from executing a container process when inside a non-container path and thus eliminates attacks 1 and 2 even in the case of fd leaks. Close all internal runc file descriptors in the final stage of runc init, right before execve. This ensures that internal file descriptors cannot be used as an argument to execve and thus eliminates attacks 3a and 3b, even in the case of fd leaks. This requires hooking into some Go runtime internals to make sure we don't close critical Go internal file descriptors. Fixing the specific fd leaks that made these bug exploitable (mark /sys/fs/cgroup as OCLOEXEC and backport a fix for some os.File leaks). In order to protect against future runc init file descriptor leaks, mark all non-stdio files as OCLOEXEC before executing runc init.
Other Runtimes
We have discovered that several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature. We recommend other container runtime authors look at our patches and make sure they at least add a getcwd() != ENOENT check as well as consider whether closerange(3, UINTMAX, CLOSERANGECLOEXEC) before executing their equivalent of runc init is appropriate.
crun 1.12 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell), but no care is taken to make sure all non-stdio files are OCLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to crun are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of crun can lead to these attacks becoming exploitable. youki 0.3.1 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell) however this appears to be pure luck. youki does leak a directory file descriptor from the host mount namespace, but it just so happens that the directory is the rootfs of the container (which then gets pivotroot'd into and so ends up as a in-root path thanks to chrootfsrefs). In addition, no care is taken to make sure all non-stdio files are OCLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to youki are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of youki can lead to these attacks becoming exploitable. LXC 5.0.3 does not appear to leak any useful file descriptors, and they have comments noting the importance of not leaking file descriptors in lxc-attach. However, they don't seem to have any proactive protection against file descriptor leaks at the point of chdir such as using closerange(...) (they do have RAII-like dofclose closers but those don't necessarily stop all leaks in this context) nor do they have any check after chdir(2) to ensure the working directory is inside the container. Unfortunately it seems they cannot use CLOSERANGECLOEXEC because they don't need to re-exec themselves.
Workarounds For attacks 1 and 2, only permit containers (and runc exec) to use a process.cwd of /. It is not possible for / to be replaced with a symlink (the path is resolved from within the container's mount namespace, and you cannot change the root of a mount namespace or an fs root to a symlink).
For attacks 1 and 3a, only permit users to run trusted images.
For attack 3b, there is no practical workaround other than never using runc exec because any binary you try to execute with runc exec could end up being a malicious binary target.
See Also https://www.cve.org/CVERecord?id=CVE-2024-21626 https://github.com/opencontainers/runc/releases/tag/v1.1.12 The runc 1.1.12 merge commit https://github.com/opencontainers/runc/commit/a9833ff391a71b30069a6c3f816db113379a4346, which contains the following security patches: https://github.com/opencontainers/runc/commit/506552a88bd3455e80a9b3829568e94ec0160309 https://github.com/opencontainers/runc/commit/0994249a5ec4e363bfcf9af58a87a722e9a3a31b https://github.com/opencontainers/runc/commit/fbe3eed1e568a376f371d2ced1b4ac16b7d7adde https://github.com/opencontainers/runc/commit/284ba3057e428f8d6c7afcc3b0ac752e525957df https://github.com/opencontainers/runc/commit/b6633f48a8c970433737b9be5bfe4f25d58a5aa7 https://github.com/opencontainers/runc/commit/683ad2ff3b01fb142ece7a8b3829de17150cf688 https://github.com/opencontainers/runc/commit/e9665f4d606b64bf9c4652ab2510da368bfbd951
Credits
Thanks to Rory McNamara from Snyk for discovering and disclosing the original vulnerability (attack 1) to Docker, @lifubang from acmcoder for discovering how to adapt the attack to overwrite host binaries (attack 3a), and Aleksa Sarai from SUSE for discovering how to adapt the attacks to work as container breakouts using runc exec (attacks 2 and 3b).
Impact ###
This attack is primarily a more sophisticated version of CVE-2019-19921, which was a flaw which 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 runc applied for CVE-2019-19921 was fairly limited and effectively only caused runc to verify that when runc writes LSM labels that those labels are actual procfs files.
Rather than using a fake tmpfs file for /proc/self/attr/<label>, an attacker could instead (through various means) make /proc/self/attr/<label> reference a real procfs file, but one that would still be a no-op (such as /proc/self/sched). This would have the same effect but would clear the "is a procfs file" check. Runc is aware that this kind of attack would be possible (even going so far as to discuss this publicly as "future work" at conferences), and runc is working on a far more comprehensive mitigation of this attack, but this security issue was disclosed before runc could complete this work.
In all known versions of runc, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (runc has 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.
Note that while /proc/self/attr/<label> was the example used above (which is LSM-specific), this issue affect all writes to /proc in runc and thus also affects sysctls (written to /proc/sys/...) and some other APIs.
Additional Impacts ####
While investigating this issue, runc discovered that another risk with these redirected writes is that they could be redirected to dangerous files such as /proc/sysrq-trigger rather than just no-op files like /proc/self/sched. For instance, the default AppArmor profile name in Docker is docker-default, which when written to /proc/sysrq-trigger would cause the host system to crash.
When this was discovered, runc conducted an audit of other write operations within runc and found several possible areas where runc could be used as a semi-arbitrary write gadget when combined with the above race attacks. The most concerning attack scenario was the configuration of sysctls. Because the contents of the sysctl are free-form text, an attacker could use a misdirected write to write to /proc/sys/kernel/corepattern and break out of the container (as described in CVE-2025-31133, kernel upcalls are not namespaced and so coredump helpers will run with complete root privileges on the host). Even if the attacker cannot configure custom sysctls, a valid sysctl string (when redirected to /proc/sysrq-trigger) can easily cause the machine to hang.
Note that the fact that this attack allows you to disable LSM labels makes it a very useful attack to combine with CVE-2025-31133 (as one of the only mitigations available to most users for that issue is AppArmor, and this attack would let you bypass that). However, the misdirected write issue above means that you could also achieve most of the same goals without needing to chain together attacks.
Patches ###
This advisory is being published as part of a set of three advisories:
CVE-2025-31133 CVE-2025-52881 CVE-2025-52565
The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:
db19bbed5348 ("internal/sys: add VerifyInode helper") 6fc191449109 ("internal: move utils.MkdirAllInRoot to internal/pathrs") ff94f9991bd3 (": switch to safer securejoin.Reopen") 44a0fcf685db ("go.mod: update to github.com/cyphar/filepath-securejoin@v0.5.0") 77889b56db93 ("internal: add wrappers for securejoin.Proc") fdcc9d3cad2f ("apparmor: use safe procfs API for labels") ff6fe1324663 ("utils: use safe procfs for /proc/self/fd loop code") b3dd1bc562ed ("utils: remove unneeded EnsureProcHandle") 77d217c7c377 ("init: write sysctls using safe procfs API") 435cc81be6b7 ("init: use securejoin for /proc/self/setgroups") d61fd29d854b ("libct/system: use securejoin for /proc/$pid/stat") 4b37cd93f86e ("libct: align param type for mountCgroupV1/V2 functions") d40b3439a961 ("rootfs: switch to fd-based handling of mountpoint targets") ed6b1693b8b3 ("selinux: use safe procfs API for labels") - Please note that this patch includes a private patch for github.com/opencontainers/selinux that could not be made public through a public pull request (as it would necessarily disclose this embargoed security issue).
The patch includes a complete copy of the forked code and a replace directive (as well as go mod vendor applied), which should still work with downstream build systems. If you cannot apply this patch, you can safely drop it -- some of the other patches in this series should block these kinds of racing mount attacks entirely.
See https://github.com/opencontainers/selinux/pull/237 for the upstream patch. 3f925525b44d ("rootfs: re-allow dangling symlinks in mount targets") a41366e74080 ("openat2: improve resilience on busy systems")
runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per [runc's new release model][RELEASES.md], runc 1.1.x and earlier are no longer supported and thus have not been patched.
[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2 [CVE-2025-52565]: https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r [CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm [RELEASES.md]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md
Mitigations ###
Do not run untrusted container images from unknown or unverified sources.
For the basic no-op attack, this attack allows a container process to run with the same LSM labels as runc. For most AppArmor deployments this means it will be unconfined, and for SELinux it will likely be containerruntimet. Runc has not conducted in-depth testing of the impact on SELinux -- it is possible that it provides some reasonable protection but it seems likely that an attacker could cause harm to systems even with such an SELinux setup.
For the more involved redirect and write gadget attacks, unfortunately most LSM profiles (including the standard container-selinux profiles) provide the container runtime access to sysctl files (including /proc/sysrq-trigger) and so LSMs likely do not provide much protection against these attacks.
Using rootless containers provides some protection against these kinds of bugs (privileged writes in runc being redirected) -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. For this particular bug, the privilege escalation caused by the inadvertent write issue is entirely mitigated with rootless containers because the unprivileged user that the runc process is executing as cannot write to the aforementioned procfs files (even intentionally).
Other Runtimes ###
As this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.
Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to use the host's /proc for all procfs operations, and so is likely not vulnerable to this issue (this is a trade-off -- runc uses the container's procfs to avoid CVE-2016-9962-style attacks).
[CVE-2016-9962]: https://seclists.org/fulldisclosure/2017/Jan/21
Credits ###
Thanks to Li Fubang (@lifubang from acmcoder.com, CIIC) and Tõnis Tiigi (@tonistiigi from Docker) for both independently discovering this vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for the original research into this class of security issues and solutions.
Additional thanks go to Tõnis Tiigi for finding some very useful exploit templates for these kinds of race attacks using docker buildx build.
Impact ### 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).
In runc version 1.0.0-rc3 and later, 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 happens after pivotroot(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/corepattern (respectively).
The reason that the attacker can gain write access to these files is because the /dev/console bind-mount happens before maskedPaths and readonlyPaths are applied.
Additional Findings #### While investigating this issue, runc discovered some other theoretical issues that may or may not be exploitable, as well as taking the opportunity to fix some fairly well-known issues related to consoles.
Issue 1: Problematic Usage of os.Create ##### Go provides an os.Create function for creating files, which older code in runc (dating back to the original libcontainer from the early 2010s) had a tendency to use fairly liberally. os.Create implies OCREAT|OTRUNC but by design it does not apply ONOFOLLOW nor OEXCL, meaning if the target is swapped with a malicious symlink runc can be tricked into truncating host files (which can lead to denial of service attacks, among other concerns).
Runc conducted an audit of all os.Create usages in runc and found some suspicious usages related to device inodes, but based on runc's testing these were not exploitable in practice. Runc now has custom code lints to block any os.Create usage in runc, and plan to do a further audit of any other plain os. operation usage throughout runc after this advisory becomes public.
CVE-2024-45310 was a similar attack but without the OTRUNC component (which resulted in a "Low" severity) -- a similar attack being exploitable would've been much more severe.
Issue 2: Malicious /dev/pts/$n Inode Attacks (TIOCGPTPEER) ##### The (very) classic API for constructing consoles involves first opening /dev/ptmx for reading and writing. This allocates a new pseudo-terminal and the returned file descriptor is the "master" end (which is used by higher-level runtimes to do I/O with the container).
Traditionally, in order to get the "slave" end, you do ioctl(ptm, TIOCGPTN) to get the pseudo-terminal number and then open the file in /dev/pts/ with the corresponding base-10 decimal number of the number returned by TIOCGPTN. The naive way of doing this is vulnerable to very basic race attacks where /dev/pts/$n is replaced with a different pseudo-terminal or other malicious file.
In order to provide a mechanism to mitigate this risk, Aleksa Sarai (@cyphar from SUSE) implemented TIOCGPTPEER back in 2017 to provide a race-free way of doing the last TIOCGPTN step by opening the peer end of the pseudo-terminal directly. However, at the time it was believed to be too impractical to implement this protection in runc due to its no-monitor-process architecture (unlike runtimes like LXC which made use of TIOCGPTPEER almost immediately). While working on this advisory, runc found a way to make TIOCGPTN usage on pre-4.13 kernels still safe against race attacks and so have implemented both TIOCGPTPEER support as well as safe TIOCGPTN support as a fallback.
Another possible target of attack would be replacing /dev/ptmx or /dev/pts/ptmx with a different inode and tricking runc into trying to operate on it. This is very similar to the core issue in CVE-2025-31133 and had a similar solution.
Runc's analysis was that while this attack appears to be potentially problematic in theory, it seems unlikely to actually be exploitable due to how consoles are treated (runc tries to do several pseudo-terminal-specific ioctls and will error out if they fail -- which happens for most other file types). In principle you could imagine a DoS attack using a disconnected NFS handle but it seems impractical to exploit. However, runc felt it prudent to include a solution (and this also provides a safe mechanism to get the source mount for the /dev/console bind-mount issue at the beginning of this advisory).
Patches ### This advisory is being published as part of a set of three advisories:
CVE-2025-31133 CVE-2025-52881 CVE-2025-52565
The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:
db19bbed5348 ("internal/sys: add VerifyInode helper") ff94f9991bd3 (": switch to safer securejoin.Reopen") 531ef794e4ec ("console: use TIOCGPTPEER when allocating peer PTY") 398955bccb7f ("console: add fallback for pre-TIOCGPTPEER kernels") 9be1dbf4ac67 ("console: avoid trivial symlink attacks for /dev/console") de87203e625c ("console: verify /dev/pts/ptmx before use") 01de9d65dc72 ("rootfs: avoid using os.Create for new device inodes") aee7d3fe355d ("ci: add lint to forbid the usage of os.Create")
runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched.
[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2 [CVE-2025-52565]: https://github.com/opencontainers/runc/security/advisories/GHSA-qw9x-cqr3-wc7r [CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm [RELEASES.md]: https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md
Mitigations ### Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the procfs files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.
An attacker would still be able to bind-mount host paths into the container but if the host uids and gids mapped into the container do not overlap with ordinary users on the host (which is the generally recommended configuration) then the attacker would likely not be able to read or write to most sensitive host files (depending on the Unix DAC permissions of the host files). Note that this is still technically more privilege than an unprivileged user on the host -- because the bind-mount is done by a privileged process, the attacker would be able to get access to directories whose parents may have denied search access (i.e., they may be able to access paths inside a chmod 700 directory that would normally block them from resolving subpaths).
Runc would also like to take this opportunity to re-iterate that runc strongly recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation inside the container -- most container runtimes apply a seccomp-bpf profile which blocks unshare(CLONENEWUSER) inside containers regardless of whether the container itself uses user namespaces.
Rootless containers can provide even more protection if your configuration can use them -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc.
For non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling noNewPrivileges to disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use ping in your containers, there is a net.ipv4.pinggrouprange sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries. Do not run untrusted container images from unknown or unverified sources. The default containers-selinux SELinux policy mitigates this issue, as (unlike CVE-2025-31133) the /dev/console bind-mount does not get relabeled and so the container process cannot write to the bind-mounted procfs file by default.
Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881.
The default AppArmor policy used by Docker and Podman does not mitigate this issue (as access to /dev/console) is usually permitted. Users could create a custom profile that blocks access to /dev/console, but such a profile might break regular containers.
Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so the mitigation provided with a custom profile is not that helpful when considered in combination with CVE-2025-52881.
[CVE-2025-31133]: https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2 [CVE-2025-52881]: https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm
Other Runtimes ### As this vulnerability boils down to a fairly easy-to-make logic bug,runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability.
Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a co-ordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but [their security stance][lxc-security] is (understandably) that non-user-namespaced containers are fundamentally insecure by design.
[lxc-security]: https://linuxcontainers.org/lxc/security/
Credits ###
Thanks to Lei Wang (@ssst0n3 from Huawei) and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering and reporting the main /dev/console bind-mount vulnerability, as well as Aleksa Sarai (@cyphar from SUSE) for discovering Issues 1 and 2 and the original research into these classes of issues several years ago.
Impact ### The OCI runtime specification has a maskedPaths feature that allows for files or directories to be "masked" by placing a mount on top of them to conceal their contents. This is primarily intended to protect against privileged users in non-user-namespaced from being able to write to files or access directories that would either provide sensitive information about the host to containers or allow containers to perform destructive or other privileged operations on the host (examples include /proc/kcore, /proc/timerlist, /proc/acpi, and /proc/keys).
maskedPaths can be used to either mask a directory or a file -- directories are masked using a new read-only tmpfs instance that is mounted on top of the masked path, while files are masked by bind-mounting the container's /dev/null on top of the masked path.
In all known versions of runc, when using the container's /dev/null to mask files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode. While /dev/null is usually created by runc when doing container creation, it is possible for an attacker to create a /dev/null or modify the /dev/null inode created by runc through race conditions with other containers sharing mounts (runc has 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 could lead to two separate issues:
Attack 1: Arbitrary Mount Gadget (leading to Host Information Disclosure, Host Denial of Service, or Container Escape) #### By replacing /dev/null with a symlink to an attacker-controlled path, an attacker could cause runc to bind-mount an arbitrary source path to a path inside the container. This could lead to: Host Denial of Service: By bind-mounting files such as /proc/sysrq-trigger, the attacker can gain access to a read-write version of files which can be destructive to write to (/proc/sysrq-trigger would allow an attacker to trigger a kernel panic, shutting down the machine, or causing the machine to freeze without rebooting). Container Escape: By bind-mounting /proc/sys/kernel/corepattern, the attacker can reconfigure a coredump helper -- as kernel upcalls are not namespaced, the configured binary (which could be a container binary or a host binary with a malicious command-line) will run with full privileges on the host system. Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.
Note that while config.json allows users to bind-mount arbitrary paths (and thus an attacker that can modify config.json arbitrarily could gain the same access as this exploit), because maskedPaths is applied by almost all higher-level container runtimes (and thus provides a guaranteed mount source) this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals.
Attack 2: Bypassing maskedPaths #### While investigating Attack 1, runc discovered that the runc validation mechanism when bind-mounting /dev/null for maskedPaths would ignore ENOENT errors -- meaning that if an attacker deleted /dev/null before runc did the bind-mount, runc would silently skip applying maskedPaths for the container. (The original purpose of this ENOENT-ignore behaviour was to permit configurations where maskedPaths references non-existent files, but runc did not consider that the source path could also not exist in this kind of race-attack scenario.)
With maskedPaths rendered inoperative, an attacker would be able to access sensitive host information from files in /proc that would usually be masked (such as /proc/kcore). However, note that /proc/sys and /proc/sysrq-trigger are mounted read-only rather than being masked with files, so this attack variant will not allow the same breakout or host denial of service attacks as in Attack 1.
Patches ### This advisory is being published as part of a set of three advisories: CVE-2025-31133 CVE-2025-52881 CVE-2025-52565
The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory: db19bbed5348 ("internal/sys: add VerifyInode helper") 8476df83b534 ("libct: add/use isDevNull, verifyDevNull") 1a30a8f3d921 ("libct: maskPaths: only ignore ENOENT on mount dest") 5d7b24240724 ("libct: maskPaths: don't rely on ENOTDIR for mount")
runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched. https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md
Mitigations ### - Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the procfs files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.
runc would also like to take this opportunity to re-iterate that runc strongly recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation inside the container -- most container runtimes apply a seccomp-bpf profile which blocks unshare(CLONENEWUSER) inside containers regardless of whether the container itself uses user namespaces.
Rootless containers can provide even more protection if your configuration can use them -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc.
- For non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling noNewPrivileges to disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use ping in your containers, there is a net.ipv4.pinggrouprange sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries. - Do not run untrusted container images from unknown or unverified sources. - Depending on the configuration of maskedPaths, an AppArmor profile (such as the default one applied by higher level runtimes including Docker and Podman) can block write attempts to most of /proc and /sys. This means that even with a procfs file maliciously bind-mounted to a maskedPaths target, all of the targets of maskedPaths in the default configuration of runtimes such as Docker or Podman will still not permit write access to said files. However, if a container is configured with a maskedPaths that is not protected by AppArmor then the same attack can be carried out. Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881. - Based on runc's analysis, SELinux policies have a limited effect when trying to protect against this attack. The reason is that the /dev/null bind-mount gets implicitly relabelled with context=... set to the container's SELinux context, and thus the container process will have access to the source of the bind-mount even if they otherwise wouldn't. https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm
Other Runtimes ### As this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability. Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a coordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but their security stance is (understandably) that non-user-namespaced containers are fundamentally insecure by design. https://linuxcontainers.org/lxc/security/
Credits ### Thanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector (Attack 2) based on @ssst0n3's initial findings.
Impact 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.
Please note that this issue is not exploitable under Docker because it creates a top-level ro layer that masks any malicious /dev symlink present in the container image (this is also done without mounting the lower layers so there is no opportunity for the malicious /dev symlink to trick it into resolving to some other path). Unfortunately, Podman and containerd<sup>†</sup> do not do this and so users using those higher-level runtimes with runc can be exploited via a malicious image.
This issue mirrors a somewhat similar issue in crun, which was also published recently.
† Actually, at the time the issue was analysed, containerd had dead code that implemented this feature but the implementation contained several security issues that would arguably have made it more exploitable than in runc. Luckily, the code appears to have never been used (at least since 2017) and the code has since been removed.
Mitigating Factors ####
There are a few mitigating factors about this issue which reduce the impact for most users quite significantly, and is the reason why we decided to release the fix publicly without an embargo.
While the deletion of ptmx seems like a significant issue, in practice it is quite limited. Notably, devpts does not permit you to unlink /dev/pts/ptmx regardless of privileges and so it is not a usable target for this attack. Additionally, while /dev/ptmx can be unlinked<sup>‡</sup>, trying to use an image with a symlink from /dev to /dev will cause runc will return an error before it reaches the buggy code (it correctly detects a symlink loop while setting up the mount target and the code correctly scopes the lookup inside the container). Thus, the only files called ptmx that are guaranteed to exist on the system cannot actually be removed by this bug and so only some user file that happens to have that specific name could be deleted, which seems fairly unlikely to happen on real systems.
As for the issue of symlinks, again the impact is likely quite limited. While the creation of arbitrary symlinks could be used to create drop-in files for system services (and thus lead to a container breakout), the hardcoded set of symlink names and targets that this bug allows you to create on the host make it quite unlikely that you would be able to do much more than pollute the host system with dummy symlinks. Here is the complete list of symlinks that can be created with this attack:
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
Note that none of these symlinks are likely to point to user-controlled data -- the /proc/self/fd/$n symlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and the pts/ptmx symlink is almost certainly in the same privilege scope as the directory the symlink itself is in. It seems the only somewhat plausible impact would be that a service could return an error when trying to parse one of these symlinks and thus treat it as an invalid configuration file. How arbitrary processes deal with this situation is a bit hard to analyse, but most daemons require configuration files to have certain suffixes (such as .conf) so it's not really clear how large the impact is in practice and it seems there are a few barriers to clear to use this to cause a DoS or other problems.
‡ This would actually be quite problematic if it could occur because glibc seemingly only attempts to use /dev/ptmx when creating new terminals and thus most terminal managers (including tmux) and shell tools (including sudo -- but not su) would fail to start and thus bring the system to a halt. setupPtmx does add a symlink to /dev/pts/ptmx afterwards but on some systems the mode of the host /dev/pts/ptmx is set to 0o000 which would still cause the same DoS issue.
Patches This issue has been patched in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3.
Workarounds Using user namespaces restricts this attack fairly significantly such that the attacker can only create/delete 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 or delete inodes in world-writable directories.
LSMs can restrict the scope of where in the host filesystem runc can be tricked into operating on, though how much this helps is questionable. The default containerruntimet SELinux label rules (or custom AppArmor rules for the host runc context) may restrict the scope where these filesystem operations can operate on, but we have not done an in-depth analysis on the impact of those kinds of LSM protections.
Resources commit opencontainers/runc@864db8042dbb ("rootfs: make /dev initialisation code fd-based") https://github.com/containers/crun/security/advisories/GHSA-7vwr-4279-7gq5
Credits runc thanks "Davias" for initially finding and reporting this issue. The same underlying issue (with varying levels of completeness) was later reported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu (@mosskappa), and Derek Manzella (@Dmanzella).
Impact 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 Fixed in runc v1.1.14 and v1.2.0-rc3.
main patches: https://github.com/opencontainers/runc/pull/4359 https://github.com/opencontainers/runc/commit/63c2908164f3a1daea455bf5bcd8d363d70328c7 release-1.1 patches: https://github.com/opencontainers/runc/commit/8781993968fd964ac723ff5f360b6f259e809a3e https://github.com/opencontainers/runc/commit/f0b652ea61ff6750a8fcc69865d45a7abf37accf
Credits Thanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from Microsoft for discovering and reporting this vulnerability.
Last updated 24 July 2024
Last updated 25 August 2025
Impact By crafting a malicious root filesystem (with /proc being a symlink to a directory which was inside a volume shared with another running container), an attacker in control of both containers can trick runc into not correctly configuring the container's security labels and not correctly masking paths inside /proc which contain potentially-sensitive information about the host (or even allow for direct attacks against the host).
In order to exploit this bug, an untrusted user must be able to spawn custom containers with custom mount configurations (such that a volume is shared between two containers). It should be noted that we consider this to be a fairly high level of access for an untrusted user -- and we do not recommend allowing completely untrusted users to have such degrees of access without further restrictions.
Specific Go Package Affected github.com/opencontainers/runc/libcontainer
Patches This vulnerability has been fixed in 1.0.0-rc10. It should be noted that the current fix is effectively a hot-fix, and there are known ways for it to be worked around (such as making the entire root filesystem a shared volume controlled by another container). We recommend that users review their access policies to ensure that untrusted users do not have such high levels of controls over container mount configuration.
Workarounds If you are not providing the ability for untrusted users to configure mountpoints for runc (or through a higher-level tool such as docker run -v) then you are not vulnerable to this issue. This exploit requires fairly complicated levels of access (which are available for some public clouds but are not necessarily available for all deployments).
Additionally, it appears as though it is not possible to exploit this vulnerability through Docker (due to the order of mounts Docker generates). However you should not depend on this, as it may be possible to work around this roadblock.
Credits This vulnerability was discovered by Cure53, as part of a third-party security audit.
For more information If you have any questions or comments about this advisory: Open an issue. Email us at dev@opencontainers.org, or security@opencontainers.org if you think you've found a security bug.
Last updated 25 August 2025
libcontainer/user/user.go in runC before 0.1.0, as used in Docker before 1.11.2, improperly treats a numeric UID as a potential username, which allows local users to gain privileges via a numeric username in the password file in a container.