runc container breakout through process.cwd trickery and leaked fds
cve-program · CVE-2024-21626
Publishedrunc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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"). runc 1.1.12 includes patches for this issue.
Read the publisher's advisoryeuvd · EUVD-2024-0459
Publishedrunc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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"). runc 1.1.12 includes patches for this issue.
Read the publisher's advisorynvd · CVE-2024-21626
Publishedrunc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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"). runc 1.1.12 includes patches for this issue.
Read the publisher's advisoryosv · GHSA-xr7r-f8xq-vfvv
Published### 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 `pivot_root(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, `PR_SET_DUMPABLE` protections no longer apply and the attacker can open `/proc/$exec_pid/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 `O_CLOEXEC` 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 `O_CLOEXEC` 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](#Patches) and make sure they at least add a `getcwd() != ENOENT` check as well as consider whether `close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC)` 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 `O_CLOEXEC` 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 `pivot_root`'d into and so ends up as a in-root path thanks to `chroot_fs_refs`). In addition, no care is taken to make sure all non-stdio files are `O_CLOEXEC` 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 `close_range(...)` (they do have RAII-like `__do_fclose` 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 `CLOSE_RANGE_CLOEXEC` 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).
Read the publisher's advisoryosv · GO-2024-2491
PublishedContainer breakout through process.cwd trickery and leaked fds in github.com/opencontainers/runc
Read the publisher's advisoryAffected versions, risk and source history
Exploitation and risk
Source statusCISA KEV lists vulnerabilities known to be exploited. FIRST EPSS estimates the likelihood of exploitation in the next 30 days. An unavailable score does not mean zero risk.
Which CVEs have scores here?
This view includes predictions for CVE identifiers explicitly listed in public NuGet advisories. Microsoft release pages have their own prediction coverage. Check source status for the scope and latest checks.
No exploitation or prediction data is available here for these CVEs. This does not mean they are safe or unlikely to be exploited.
cve-program · CVE-2024-21626
Publishedrunc container breakout through process.cwd trickery and leaked fds
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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"). runc 1.1.12 includes patches for this issue.
- Source published
- 31 Jan 2024 21:31:14 UTC
- Source modified
- 17 Sep 2026 12:04:33 UTC
- Saved here
- 23 Oct 2026 15:48:27 UTC
- Source terms
- CVE Program Terms of Use
Original source record · Cite this exact observation · Complete original publisher JSON
Source: cve-program · CVE Program Terms of Use. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 3.1 · 8.6 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
euvd · EUVD-2024-0459
Publishedrunc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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 ex…
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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"). runc 1.1.12 includes patches for this issue.
Additional publisher context
EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.
Original publisher date fields
datePublished: Jan 31, 2024, 9:31:14 PM
dateUpdated: Sep 17, 2026, 12:04:33 PM
43 related source bulletins · separate from aliases
WID-SEC-W-2024-0272: docker: Mehrere Schwachstellen
CVE-2024-21626 · CVE-2024-23651 · CVE-2024-23652 · CVE-2024-23653 · CVE-2024-23650 · CVE-2024-24557
RHSA-2025:2441: Red Hat Security Advisory: OpenShift Container Platform 4.12.74 bug fix and security update
CVE-2024-11187 · CVE-2024-11218 · CVE-2024-21626 · CVE-2024-45338 · CVE-2024-50302
RHSA-2024:0757: Red Hat Security Advisory: container-tools:4.0 security update
CVE-2024-21626
RHSA-2024:1270: Red Hat Security Advisory: docker security update
CVE-2024-21626
RHSA-2024:0670: Red Hat Security Advisory: runc security update
CVE-2024-21626
RHSA-2024:10525: Red Hat Security Advisory: Red Hat build of MicroShift 4.14.42 security update
CVE-2024-21626
openSUSE-SU-2024:13754-1: crun-1.14.4-1.1 on GA media
CVE-2024-21626
openSUSE-SU-2024:14059-1: singularity-ce-4.1.3-1.1 on GA media
CVE-2022-23538 · CVE-2022-39237 · CVE-2024-21626 · CVE-2024-23650 · CVE-2024-23651 · CVE-2024-23652 · CVE-2024-23653 · CVE-2024-3727
WID-SEC-W-2024-0794: Dell ECS: Mehrere Schwachstellen
CVE-2018-18074 · CVE-2020-10663 · CVE-2020-10672 · CVE-2020-10673 · CVE-2020-10735 · CVE-2020-10968 · CVE-2020-10969 · CVE-2020-11111 · CVE-2020-11112 · CVE-2020-11113 · CVE-2020-11612 · CVE-2020-11619 · CVE-2020-11620 · CVE-2020-11979 · CVE-2020-12762 · CVE-2020-12825 · CVE-2020-13956 · CVE-2020-14060 · CVE-2020-14061 · CVE-2020-14062 · CVE-2020-14195 · CVE-2020-15250 · CVE-2020-1945 · CVE-2020-1967 · CVE-2020-1971 · CVE-2020-24616 · CVE-2020-24750 · CVE-2020-25649 · CVE-2020-25658 · CVE-2020-26116 · CVE-2020-26137 · CVE-2020-26541 · CVE-2020-27216 · CVE-2020-27218 · CVE-2020-27223 · CVE-2020-28366 · CVE-2020-28493 · CVE-2020-29509 · CVE-2020-29511 · CVE-2020-29582 · CVE-2020-29651 · CVE-2020-35490 · CVE-2020-35491 · CVE-2020-35728 · CVE-2020-36179 · CVE-2020-36180 · CVE-2020-36181 · CVE-2020-36182 · CVE-2020-36183 · CVE-2020-36184 · CVE-2020-36185 · CVE-2020-36186 · CVE-2020-36187 · CVE-2020-36188 · CVE-2020-36189 · CVE-2020-36516 · CVE-2020-36518 · CVE-2020-36557 · CVE-2020-36558 · CVE-2020-36691 · CVE-2020-7238 · CVE-2020-8840 · CVE-2020-8908 · CVE-2020-8911 · CVE-2020-8912 · CVE-2020-9488 · CVE-2020-9493 · CVE-2020-9546 · CVE-2020-9547 · CVE-2020-9548 · CVE-2021-20190 · CVE-2021-20323 · CVE-2021-21290 · CVE-2021-21295 · CVE-2021-21409 · CVE-2021-23840 · CVE-2021-23841 · CVE-2021-2471 · CVE-2021-25642 · CVE-2021-26341 · CVE-2021-27918 · CVE-2021-28153 · CVE-2021-28165 · CVE-2021-28169 · CVE-2021-28861 · CVE-2021-29425 · CVE-2021-30560 · CVE-2021-3114 · CVE-2021-33036 · CVE-2021-33194 · CVE-2021-33195 · CVE-2021-33196 · CVE-2021-33197 · CVE-2021-33503 · CVE-2021-33655 · CVE-2021-33656 · CVE-2021-3424 · CVE-2021-34428 · CVE-2021-3449 · CVE-2021-3450 · CVE-2021-3530 · CVE-2021-36221 · CVE-2021-36373 · CVE-2021-36374 · CVE-2021-3648 · CVE-2021-36690 · CVE-2021-3711 · CVE-2021-3712 · CVE-2021-37136 · CVE-2021-37137 · CVE-2021-37404 · CVE-2021-37533 · CVE-2021-3754 · CVE-2021-3778 · CVE-2021-3796 · CVE-2021-3826 · CVE-2021-3827 · CVE-2021-38297 · CVE-2021-3872 · CVE-2021-3875 · CVE-2021-3903 · CVE-2021-3923 · CVE-2021-3927 · CVE-2021-3928 · CVE-2021-3968 · CVE-2021-3973 · CVE-2021-3974 · CVE-2021-3984 · CVE-2021-4019 · CVE-2021-4037 · CVE-2021-4069 · CVE-2021-4104 · CVE-2021-4136 · CVE-2021-4157 · CVE-2021-4166 · CVE-2021-41771 · CVE-2021-4192 · CVE-2021-4193 · CVE-2021-4203 · CVE-2021-42567 · CVE-2021-43797 · CVE-2021-44531 · CVE-2021-44532 · CVE-2021-44533 · CVE-2021-44716 · CVE-2021-44878 · CVE-2021-45078 · CVE-2021-46195 · CVE-2021-46828 · CVE-2021-46848 · CVE-2022-0128 · CVE-2022-0213 · CVE-2022-0225 · CVE-2022-0261 · CVE-2022-0318 · CVE-2022-0319 · CVE-2022-0351 · CVE-2022-0359 · CVE-2022-0361 · CVE-2022-0392 · CVE-2022-0407 · CVE-2022-0413 · CVE-2022-0561 · CVE-2022-0696 · CVE-2022-0778 · CVE-2022-1184 · CVE-2022-1245 · CVE-2022-1271 · CVE-2022-1292 · CVE-2022-1381 · CVE-2022-1420 · CVE-2022-1462 · CVE-2022-1466 · CVE-2022-1471 · CVE-2022-1586 · CVE-2022-1587 · CVE-2022-1616 · CVE-2022-1619 · CVE-2022-1620 · CVE-2022-1679 · CVE-2022-1705 · CVE-2022-1720 · CVE-2022-1729 · CVE-2022-1733 · CVE-2022-1735 · CVE-2022-1771 · CVE-2022-1785 · CVE-2022-1796 · CVE-2022-1851 · CVE-2022-1897 · CVE-2022-1898 · CVE-2022-1927 · CVE-2022-1962 · CVE-2022-1968 · CVE-2022-1974 · CVE-2022-1975 · CVE-2022-20132 · CVE-2022-20141 · CVE-2022-20154 · CVE-2022-20166 · CVE-2022-20368 · CVE-2022-20369 · CVE-2022-2047 · CVE-2022-2048 · CVE-2022-20567 · CVE-2022-2068 · CVE-2022-2097 · CVE-2022-21216 · CVE-2022-21233 · CVE-2022-2124 · CVE-2022-2125 · CVE-2022-2126 · CVE-2022-2129 · CVE-2022-21363 · CVE-2022-21385 · CVE-2022-21499 · CVE-2022-2153 · CVE-2022-21540 · CVE-2022-21541 · CVE-2022-21549 · CVE-2022-21618 · CVE-2022-21619 · CVE-2022-21624 · CVE-2022-21626 · CVE-2022-21628 · CVE-2022-21702 · CVE-2022-2175 · CVE-2022-2182 · CVE-2022-2183 · CVE-2022-2206 · CVE-2022-2207 · CVE-2022-2208 · CVE-2022-2210 · CVE-2022-2231 · CVE-2022-2256 · CVE-2022-2257 · CVE-2022-2264 · CVE-2022-2284 · CVE-2022-2285 · CVE-2022-2286 · CVE-2022-2287 · CVE-2022-22976 · CVE-2022-22978 · CVE-2022-2304 · CVE-2022-2318 · CVE-2022-23302 · CVE-2022-23305 · CVE-2022-23307 · CVE-2022-2343 · CVE-2022-2344 · CVE-2022-2345 · CVE-2022-23471 · CVE-2022-23521 · CVE-2022-23772 · CVE-2022-23773 · CVE-2022-24302 · CVE-2022-24329 · CVE-2022-24823 · CVE-2022-24903 · CVE-2022-2503 · CVE-2022-25147 · CVE-2022-25168 · CVE-2022-2519 · CVE-2022-2520 · CVE-2022-2521 · CVE-2022-2522 · CVE-2022-25647 · CVE-2022-2571 · CVE-2022-2580 · CVE-2022-2581 · CVE-2022-25857 · CVE-2022-2588 · CVE-2022-2598 · CVE-2022-26148 · CVE-2022-26365 · CVE-2022-26373 · CVE-2022-2639 · CVE-2022-26612 · CVE-2022-2663 · CVE-2022-27781 · CVE-2022-27782 · CVE-2022-27943 · CVE-2022-2795 · CVE-2022-28131 · CVE-2022-2816 · CVE-2022-2817 · CVE-2022-2819 · CVE-2022-28327 · CVE-2022-2845 · CVE-2022-2849 · CVE-2022-2862 · CVE-2022-2867 · CVE-2022-2868 · CVE-2022-2869 · CVE-2022-28693 · CVE-2022-2874 · CVE-2022-28748 · CVE-2022-2880 · CVE-2022-2889 · CVE-2022-29162 · CVE-2022-29187 · CVE-2022-2923 · CVE-2022-2946 · CVE-2022-29526 · CVE-2022-29583 · CVE-2022-2964 · CVE-2022-2977 · CVE-2022-2980 · CVE-2022-2982 · CVE-2022-29900 · CVE-2022-29901 · CVE-2022-2991 · CVE-2022-3016 · CVE-2022-3028 · CVE-2022-3037 · CVE-2022-30580 · CVE-2022-30630 · CVE-2022-30631 · CVE-2022-30632 · CVE-2022-30633 · CVE-2022-3099 · CVE-2022-31030 · CVE-2022-31159 · CVE-2022-3134 · CVE-2022-3153 · CVE-2022-3169 · CVE-2022-31690 · CVE-2022-32148 · CVE-2022-32149 · CVE-2022-32206 · CVE-2022-32208 · CVE-2022-32221 · CVE-2022-3234 · CVE-2022-3235 · CVE-2022-3239 · CVE-2022-3278 · CVE-2022-3296 · CVE-2022-3297 · CVE-2022-33196 · CVE-2022-3324 · CVE-2022-3352 · CVE-2022-33740 · CVE-2022-33741 · CVE-2022-33742 · CVE-2022-33972 · CVE-2022-33981 · CVE-2022-34169 · CVE-2022-3424 · CVE-2022-34266 · CVE-2022-34526 · CVE-2022-34903 · CVE-2022-3491 · CVE-2022-3515 · CVE-2022-3520 · CVE-2022-3521 · CVE-2022-3524 · CVE-2022-35252 · CVE-2022-3542 · CVE-2022-3545 · CVE-2022-3564 · CVE-2022-3565 · CVE-2022-3566 · CVE-2022-3567 · CVE-2022-35737 · CVE-2022-3586 · CVE-2022-3591 · CVE-2022-3594 · CVE-2022-3597 · CVE-2022-3599 · CVE-2022-36109 · CVE-2022-3621 · CVE-2022-3626 · CVE-2022-3627 · CVE-2022-3628 · CVE-2022-36280 · CVE-2022-3629 · CVE-2022-3635 · CVE-2022-3643 · CVE-2022-36437 · CVE-2022-3646 · CVE-2022-3649 · CVE-2022-36760 · CVE-2022-36879 · CVE-2022-36946 · CVE-2022-3705 · CVE-2022-37434 · CVE-2022-37436 · CVE-2022-37865 · CVE-2022-37866 · CVE-2022-38090 · CVE-2022-38096 · CVE-2022-38126 · CVE-2022-38127 · CVE-2022-38177 · CVE-2022-38178 · CVE-2022-3821 · CVE-2022-38533 · CVE-2022-38749 · CVE-2022-38750 · CVE-2022-38751 · CVE-2022-38752 · CVE-2022-39028 · CVE-2022-3903 · CVE-2022-39188 · CVE-2022-39399 · CVE-2022-3970 · CVE-2022-40149 · CVE-2022-40150 · CVE-2022-40151 · CVE-2022-40152 · CVE-2022-40153 · CVE-2022-40303 · CVE-2022-40304 · CVE-2022-40307 · CVE-2022-40674 · CVE-2022-40768 · CVE-2022-40899 · CVE-2022-4095 · CVE-2022-41218 · CVE-2022-4129 · CVE-2022-4141 · CVE-2022-41717 · CVE-2022-41721 · CVE-2022-41848 · CVE-2022-41850 · CVE-2022-41854 · CVE-2022-41858 · CVE-2022-41881 · CVE-2022-41903 · CVE-2022-41915 · CVE-2022-41966 · CVE-2022-41974 · CVE-2022-42003 · CVE-2022-42004 · CVE-2022-42010 · CVE-2022-42011 · CVE-2022-42012 · CVE-2022-42328 · CVE-2022-42329 · CVE-2022-42703 · CVE-2022-42889 · CVE-2022-42895 · CVE-2022-42896 · CVE-2022-42898 · CVE-2022-4292 · CVE-2022-4293 · CVE-2022-42969 · CVE-2022-4304 · CVE-2022-43552 · CVE-2022-43680 · CVE-2022-43750 · CVE-2022-4378 · CVE-2022-43945 · CVE-2022-43995 · CVE-2022-4415 · CVE-2022-4450 · CVE-2022-44638 · CVE-2022-45061 · CVE-2022-45688 · CVE-2022-45884 · CVE-2022-45885 · CVE-2022-45886 · CVE-2022-45887 · CVE-2022-45919 · CVE-2022-45934 · CVE-2022-45939 · CVE-2022-4662 · CVE-2022-46751 · CVE-2022-46908 · CVE-2022-47629 · CVE-2022-47929 · CVE-2022-48281 · CVE-2022-48337 · CVE-2022-48339 · CVE-2023-0045 · CVE-2023-0049 · CVE-2023-0051 · CVE-2023-0054 · CVE-2023-0215 · CVE-2023-0286 · CVE-2023-0288 · CVE-2023-0433 · CVE-2023-0464 · CVE-2023-0465 · CVE-2023-0466 · CVE-2023-0512 · CVE-2023-0590 · CVE-2023-0597 · CVE-2023-0833 · CVE-2023-1076 · CVE-2023-1095 · CVE-2023-1118 · CVE-2023-1127 · CVE-2023-1170 · CVE-2023-1175 · CVE-2023-1370 · CVE-2023-1380 · CVE-2023-1390 · CVE-2023-1436 · CVE-2023-1513 · CVE-2023-1611 · CVE-2023-1670 · CVE-2023-1855 · CVE-2023-1989 · CVE-2023-1990 · CVE-2023-1998 · CVE-2023-20862 · CVE-2023-2124 · CVE-2023-2162 · CVE-2023-2176 · CVE-2023-21830 · CVE-2023-21835 · CVE-2023-21843 · CVE-2023-21930 · CVE-2023-21937 · CVE-2023-21938 · CVE-2023-21939 · CVE-2023-2194 · CVE-2023-21954 · CVE-2023-21967 · CVE-2023-21968 · CVE-2023-22490 · CVE-2023-2253 · CVE-2023-22809 · CVE-2023-23454 · CVE-2023-23455 · CVE-2023-23559 · CVE-2023-23916 · CVE-2023-23946 · CVE-2023-24329 · CVE-2023-24532 · CVE-2023-24534 · CVE-2023-2483 · CVE-2023-24998 · CVE-2023-2513 · CVE-2023-25193 · CVE-2023-25652 · CVE-2023-25690 · CVE-2023-25809 · CVE-2023-25815 · CVE-2023-26048 · CVE-2023-26049 · CVE-2023-2650 · CVE-2023-26545 · CVE-2023-26604 · CVE-2023-27533 · CVE-2023-27534 · CVE-2023-27535 · CVE-2023-27536 · CVE-2023-27538 · CVE-2023-27561 · CVE-2023-2828 · CVE-2023-28320 · CVE-2023-28321 · CVE-2023-28322 · CVE-2023-28328 · CVE-2023-28464 · CVE-2023-28486 · CVE-2023-28487 · CVE-2023-28642 · CVE-2023-28772 · CVE-2023-28840 · CVE-2023-28841 · CVE-2023-28842 · CVE-2023-29007 · CVE-2023-29383 · CVE-2023-29402 · CVE-2023-29406 · CVE-2023-29409 · CVE-2023-2976 · CVE-2023-30630 · CVE-2023-30772 · CVE-2023-31084 · CVE-2023-3138 · CVE-2023-31436 · CVE-2023-31484 · CVE-2023-32269 · CVE-2023-32697 · CVE-2023-33264 · CVE-2023-34034 · CVE-2023-34035 · CVE-2023-34453 · CVE-2023-34454 · CVE-2023-34455 · CVE-2023-34462 · CVE-2023-35116 · CVE-2023-3635 · CVE-2023-36479 · CVE-2023-39533 · CVE-2023-40167 · CVE-2023-40217 · CVE-2023-41105 · CVE-2023-41900 · CVE-2023-43642 · CVE-2023-43804 · CVE-2023-44487 · CVE-2023-45803 · CVE-2024-21626
RHSA-2024:0752: Red Hat Security Advisory: container-tools:rhel8 security update
CVE-2024-21626
RHSA-2025:1711: Red Hat Security Advisory: OpenShift Container Platform 4.15.46 bug fix and security update
CVE-2024-21626 · CVE-2024-45338 · CVE-2024-53104
openSUSE-SU-2025:0074-1: Security update for crun
CVE-2024-21626 · CVE-2025-24965
RHSA-2024:0756: Red Hat Security Advisory: runc security update
CVE-2024-21626
WID-SEC-W-2024-0869: Oracle Communications: Mehrere Schwachstellen
CVE-2022-40152 · CVE-2022-40896 · CVE-2022-45688 · CVE-2023-2283 · CVE-2023-31122 · CVE-2023-33201 · CVE-2023-34053 · CVE-2023-34055 · CVE-2023-4016 · CVE-2023-41056 · CVE-2023-43496 · CVE-2023-44487 · CVE-2023-45142 · CVE-2023-4641 · CVE-2023-46589 · CVE-2023-47100 · CVE-2023-4863 · CVE-2023-48795 · CVE-2023-49083 · CVE-2023-5072 · CVE-2023-51074 · CVE-2023-51257 · CVE-2023-51775 · CVE-2023-5341 · CVE-2023-5363 · CVE-2023-6507 · CVE-2024-1635 · CVE-2024-21626 · CVE-2024-22201 · CVE-2024-22233 · CVE-2024-22257 · CVE-2024-22259 · CVE-2024-25062 · CVE-2024-26130 · CVE-2024-26308
RHSA-2024:10149: Red Hat Security Advisory: Red Hat build of MicroShift 4.16.24 security update
CVE-2024-21626
RHSA-2024:10520: Red Hat Security Advisory: OpenShift Container Platform 4.17.7 security update
CVE-2024-21626
RHSA-2024:0758: Red Hat Security Advisory: container-tools:2.0 security update
CVE-2024-21626
RHSA-2024:0717: Red Hat Security Advisory: runc security update
CVE-2024-21626
RHSA-2024:0755: Red Hat Security Advisory: runc security update
CVE-2024-21626
RHSA-2024:0748: Red Hat Security Advisory: container-tools:4.0 security update
CVE-2023-39326 · CVE-2023-45287 · CVE-2024-21626
RHSA-2024:10841: Red Hat Security Advisory: OpenShift Container Platform 4.15.41 security update
CVE-2024-21626
WID-SEC-W-2024-3377: Dell PowerProtect Data Domain: Mehrere Schwachstellen
CVE-2024-45759 · CVE-2024-48010 · CVE-2024-48011 · CVE-2017-16829 · CVE-2017-5849 · CVE-2018-7208 · CVE-2019-14889 · CVE-2020-12912 · CVE-2020-16135 · CVE-2020-1730 · CVE-2020-24455 · CVE-2020-8694 · CVE-2020-8695 · CVE-2021-27219 · CVE-2021-3565 · CVE-2021-3634 · CVE-2022-1210 · CVE-2022-1622 · CVE-2022-1996 · CVE-2022-22576 · CVE-2022-25313 · CVE-2022-27774 · CVE-2022-27775 · CVE-2022-27776 · CVE-2022-27781 · CVE-2022-27782 · CVE-2022-29361 · CVE-2022-32205 · CVE-2022-32206 · CVE-2022-32207 · CVE-2022-32208 · CVE-2022-32221 · CVE-2022-35252 · CVE-2022-40023 · CVE-2022-40090 · CVE-2022-42915 · CVE-2022-42916 · CVE-2022-43551 · CVE-2022-43552 · CVE-2022-4603 · CVE-2022-48064 · CVE-2022-48624 · CVE-2023-0461 · CVE-2023-1667 · CVE-2023-1916 · CVE-2023-20592 · CVE-2023-2137 · CVE-2023-22745 · CVE-2023-2283 · CVE-2023-23914 · CVE-2023-23915 · CVE-2023-23916 · CVE-2023-23934 · CVE-2023-25577 · CVE-2023-26965 · CVE-2023-27043 · CVE-2023-2731 · CVE-2023-27533 · CVE-2023-27534 · CVE-2023-27535 · CVE-2023-27536 · CVE-2023-27538 · CVE-2023-28319 · CVE-2023-28320 · CVE-2023-28321 · CVE-2023-28322 · CVE-2023-31083 · CVE-2023-34055 · CVE-2023-35116 · CVE-2023-38286 · CVE-2023-38469 · CVE-2023-38471 · CVE-2023-38472 · CVE-2023-38545 · CVE-2023-38546 · CVE-2023-39197 · CVE-2023-39198 · CVE-2023-39804 · CVE-2023-40217 · CVE-2023-42465 · CVE-2023-4255 · CVE-2023-45139 · CVE-2023-45322 · CVE-2023-45863 · CVE-2023-45871 · CVE-2023-46136 · CVE-2023-46218 · CVE-2023-46219 · CVE-2023-46751 · CVE-2023-48795 · CVE-2023-49083 · CVE-2023-50447 · CVE-2023-5049 · CVE-2023-50495 · CVE-2023-50782 · CVE-2023-51257 · CVE-2023-52425 · CVE-2023-52426 · CVE-2023-5678 · CVE-2023-5717 · CVE-2023-5752 · CVE-2023-6004 · CVE-2023-6597 · CVE-2023-6918 · CVE-2023-7207 · CVE-2024-0450 · CVE-2024-0727 · CVE-2024-0985 · CVE-2024-21626 · CVE-2024-22195 · CVE-2024-22365 · CVE-2024-23651 · CVE-2024-23652 · CVE-2024-23653 · CVE-2024-23672 · CVE-2024-24549 · CVE-2024-25062 · CVE-2024-26130 · CVE-2024-26458 · CVE-2024-26461 · CVE-2024-28085 · CVE-2024-28182 · CVE-2024-28219 · CVE-2024-28757
WID-SEC-W-2024-1488: IBM InfoSphere Information Server: Mehrere Schwachstellen
CVE-2020-8562 · CVE-2021-25743 · CVE-2023-22102 · CVE-2023-27561 · CVE-2023-28642 · CVE-2023-3446 · CVE-2023-35022 · CVE-2023-3817 · CVE-2023-4759 · CVE-2023-50312 · CVE-2023-50952 · CVE-2023-50953 · CVE-2023-50954 · CVE-2023-50964 · CVE-2023-51775 · CVE-2023-5363 · CVE-2023-5678 · CVE-2023-5685 · CVE-2023-6129 · CVE-2023-6237 · CVE-2024-0727 · CVE-2024-21626 · CVE-2024-22329 · CVE-2024-25026 · CVE-2024-27268 · CVE-2024-27270 · CVE-2024-28794 · CVE-2024-28795 · CVE-2024-28797 · CVE-2024-28798 · CVE-2024-31898 · CVE-2024-31902 · CVE-2024-34062 · CVE-2024-35119 · CVE-2024-35195
RHSA-2024:0662: Red Hat Security Advisory: OpenShift Container Platform 4.13.32 packages and security update
CVE-2024-21626
RHSA-2024:0759: Red Hat Security Advisory: container-tools:rhel8 security update
CVE-2024-21626
RHSA-2025:2710: Red Hat Security Advisory: OpenShift Container Platform 4.14.49 bug fix and security update
CVE-2024-9675 · CVE-2024-9676 · CVE-2024-11187 · CVE-2024-11218 · CVE-2024-21626 · CVE-2024-45338 · CVE-2024-50302 · CVE-2024-53197
SUSE-SU-2024:0328-1: Security update for runc
CVE-2024-21626
RHSA-2025:0115: Red Hat Security Advisory: OpenShift Container Platform 4.17.12 bug fix and security update
CVE-2024-21626 · CVE-2024-45338 · CVE-2024-50312
openSUSE-SU-2024:13644-1: runc-1.1.12-1.1 on GA media
CVE-2024-21626
SUSE-SU-2024:0294-1: Security update for runc
CVE-2024-21626
RHSA-2024:0764: Red Hat Security Advisory: container-tools:rhel8 security update
CVE-2024-21626
RHSA-2025:2701: Red Hat Security Advisory: OpenShift Container Platform 4.13.56 bug fix and security update
CVE-2024-9675 · CVE-2024-11218 · CVE-2024-12085 · CVE-2024-21626 · CVE-2024-45338 · CVE-2024-50302 · CVE-2024-53104 · CVE-2024-53197 · CVE-2024-56171
SUSE-SU-2024:0295-1: Security update for runc
CVE-2024-21626
RHSA-2024:0760: Red Hat Security Advisory: container-tools:3.0 security update
CVE-2024-21626
ESSA-2024:0027: security update for runc
CVE-2024-21626
ESSA-2024:0037: security update for docker
CVE-2024-21626
RHSA-2024:0645: Red Hat Security Advisory: OpenShift Container Platform 4.14.11 packages and security update
CVE-2024-21626
RHSA-2024:0666: Red Hat Security Advisory: OpenShift Container Platform 4.12.49 packages and security update
CVE-2024-21626
RHSA-2024:0684: Red Hat Security Advisory: OpenShift Container Platform 4.11.58 packages and security update
CVE-2024-21626
RHSA-2025:0650: Red Hat Security Advisory: OpenShift Container Platform 4.16.32 bug fix and security update
CVE-2023-6597 · CVE-2024-21626 · CVE-2024-45338
SUSE-SU-2024:0459-1: Security update for runc
CVE-2024-21626
RHEA-2024:6124: Red Hat Enhancement Advisory: Red Hat build of MicroShift 4.18.1 security update
CVE-2024-21626
RHSA-2024:4597: Red Hat Security Advisory: Red Hat Product OCP Tools 4.15 OpenShift Jenkins security update
CVE-2023-48795 · CVE-2024-21626 · CVE-2024-22201 · CVE-2024-23899 · CVE-2024-23900 · CVE-2024-24786 · CVE-2024-28149 · CVE-2024-34144 · CVE-2024-34145
- Source published
- Jan 31, 2024, 9:31:14 PM (timezone not stated)
- Source modified
- Sep 17, 2026, 12:04:33 PM (timezone not stated)
- Saved here
- 13 Nov 2026 01:25:24 UTC
- Source terms
- ENISA EUVD · source terms and attribution apply
Original source record · Cite this exact observation · Complete original publisher JSON
Source: euvd · ENISA EUVD · source terms and attribution apply. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
EUVD CVSS 3.1 · 8.6 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
nvd · CVE-2024-21626
Publishedrunc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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 ex…
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. 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"). runc 1.1.12 includes patches for this issue.
Additional publisher context
NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.
Source analysis status: Modified
Weakness classifications: CWE-403 · CWE-668 · CWE-200
Original publisher date fields
published: 2024-01-31T22:15:53.780
lastModified: 2026-09-17T12:17:08.273
2 source CPE criteria · context only
- cpe:2.3:a:linuxfoundation:runc:*:*:*:*:*:*:*:*
- cpe:2.3:o:fedoraproject:fedora:39:*:*:*:*:*:*:*
The original JSON retains the logical configuration operators, exclusions and version bounds.
- Source published
- 31 Jan 2024 22:15:53 UTC
- Source modified
- 17 Sep 2026 12:17:08 UTC
- Saved here
- 24 Oct 2026 23:17:22 UTC
- Source terms
- NIST NVD usage terms; underlying source attribution retained
Original source record · Cite this exact observation · Complete original publisher JSON
Source: nvd · NIST NVD usage terms; underlying source attribution retained. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS 3.1 · [email protected] · Secondary · 8.6 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
CVSS 3.1 · [email protected] · Primary · 8.6 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
CVSS 3.1 · 0b0ca135-0b70-47e7-9f44-1890c2a1c46c · Secondary · 8.6 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
osv · GHSA-xr7r-f8xq-vfvv
Publishedrunc vulnerable to container breakout through process.cwd trickery and leaked fds
### 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 `pivot_root(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, `PR_SET_DUMPABLE` protections no longer apply and the attacker can open `/proc/$exec_pid/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 `O_CLOEXEC` 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 `O_CLOEXEC` 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](#Patches) and make sure they at least add a `getcwd() != ENOENT` check as well as consider whether `close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC)` 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 `O_CLOEXEC` 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 `pivot_root`'d into and so ends up as a in-root path thanks to `chroot_fs_refs`). In addition, no care is taken to make sure all non-stdio files are `O_CLOEXEC` 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 `close_range(...)` (they do have RAII-like `__do_fclose` 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 `CLOSE_RANGE_CLOEXEC` 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).
- Source published
- 31 Jan 2024 22:44:08 UTC
- Source modified
- 10 Sep 2026 03:50:05 UTC
- Saved here
- 24 Oct 2026 13:19:41 UTC
- Source terms
- GitHub Advisory Database · CC-BY-4.0
Original source record · Cite this exact observation · Complete original publisher JSON
Source: osv · GitHub Advisory Database · CC-BY-4.0. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.
CVSS_V3 · CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
Publisher rating · HIGH
osv · GO-2024-2491
PublishedContainer breakout through process.cwd trickery and leaked fds in github.com/opencontainers/runc
Container breakout through process.cwd trickery and leaked fds in github.com/opencontainers/runc
- Source published
- 28 Jun 2024 15:28:53 UTC
- Source modified
- 4 Feb 2026 02:39:00 UTC
- Saved here
- 24 Oct 2026 13:19:41 UTC
- Source terms
- OSV · upstream source license applies
Original source record · Cite this exact observation · Complete original publisher JSON
Source: osv · OSV · upstream source license applies. The publisher's wording is preserved. ChangeIntel groups the information and labels changes. The JSON record includes additional source fields.