Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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,…
Recommended action: Upgrade to 1.5.0-rc.3 (pre-release), 1.4.3 or 1.3.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.4.0-rc.3 (pre-release), 1.3.3 or 1.2.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.4.0-rc.3 (pre-release), 1.3.3 or 1.2.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 1.4.0-rc.3 (pre-release), 1.3.3 or 1.2.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/opencontainers/runc < 1.1.14; >= 1.2.0-rc.1, < 1.2.0-rc.3
Fixed in
1.1.141.2.0-rc.3· Vendor fix available
Issue
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).…
Recommended action: Upgrade to 1.2.0-rc.3 (pre-release) or 1.1.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/opencontainers/runc >= 1.0.0-rc93, <= 1.1.11
Fixed in
1.1.12· Vendor fix available
Issue
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,…
Recommended action: Upgrade to 1.1.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It was found that AppArmor, and potentially SELinux, can be bypassed when /proc inside the container is symlinked with a specific mount configuration. Patches Fixed in runc v1.1.5, by prohibiting symlinked /proc: https://github.com/opencontainers/runc/pull/3785 This PR fixes CVE-2023-27561 as well. Workarounds Avoid using an untrusted container image.
Recommended action: Upgrade to 1.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It was found that rootless runc makes /sys/fs/cgroup writable in following conditons: 1. when runc is executed inside the user namespace, and the config.json does not specify the cgroup namespace to be unshared (e.g.., (docker|podman|nerdctl) run --cgroupns=host, with Rootless Docker/Podman/nerdctl) 2. or, when runc is executed outside the user namespace, and /sys is mounted with rbind, ro (e.g., runc spec --rootless; this condition is very rare) A container may gain the write access to user-owned cgroup hierarchy /sys/fs/cgroup/user.slice/... on the host . Other users's cgroup hierarchies are not affected. Patches v1.1.5 (planned) Workarounds - Condition 1: Unshare the cgroup namespace ((docker|podman|nerdctl) run --cgroupns=private). This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts. - Condition 2 (very rare): add /sys/fs/cgroup to maskedPaths
Recommended action: Upgrade to 1.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/opencontainers/runc >= 1.0.0-rc95, < 1.1.5
Fixed in
1.1.5· Vendor fix available
Issue
runc 1.0.0-rc95 through 1.1.4 has Incorrect Access Control leading to Escalation of Privileges, related to libcontainer/rootfslinux.go. To exploit this, an attacker must be able to spawn two containers with custom volume-mount configurations, and be able to run custom images. NOTE: this issue exists because of a CVE-2019-19921 regression.
Recommended action: Upgrade to 1.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A bug was found in runc where runc exec --cap executed processes with non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling programs with inheritable file capabilities to elevate those capabilities to the permitted set during execve(2). This bug did not affect the container security sandbox as the inheritable set never contained more capabilities than were included in the container's bounding set. Patches This bug has been fixed in runc 1.1.2. Users should update to this version as soon as possible. This fix changes runc exec --cap behavior such that the additional capabilities granted to the process being executed (as specified via --cap arguments) do not include inheritable capabilities. In addition, runc spec is changed to not set any inheritable capabilities in the created example OCI spec (config.json) file. Credits The opencontainers project would like to thank Andrew G. Morgan for responsibly disclosing this issue in…
Recommended action: Upgrade to 1.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/opencontainers/runc < 1.0.0-rc8.0.20190930145003-cad42f6e0932
Fixed in
1.0.0-rc8.0.20190930145003-cad42f6e0932· Vendor fix available
Issue
runc through 1.0.0-rc8, as used in Docker through 19.03.2-ce and other products, allows AppArmor restriction bypass because libcontainer/rootfslinux.go incorrectly checks mount targets, and thus a malicious Docker image can mount over a /proc directory.
Recommended action: Upgrade to 1.0.0-rc8.0.20190930145003-cad42f6e0932 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Contrary to the OCI runtime specification, runc's implementation of the linux.resources.devices list was a black-list by default. This means that users who created their own config.json objects and didn't prefix a deny-all rule ({"allow": false, "permissions": "rwm"} or equivalent) were not provided protection by the devices cgroup. This would allow malicious containers (with sufficient privileges) to create arbitrary device inodes (assuming they have CAPMKNOD) and operate on any device inodes they may have access to (assuming they have regular Unix DAC permissions). However, most (if not all) programs that make use of runc include this deny-all rule. This was most likely added before the specification mandated a white-list of devices, and the fact that all programs wrote their own deny-all rule obscured the existence of this bug for several years. In fact, even the specification's examples include a default deny-all rule! We therefore believe that while this is a security bug…
Recommended action: Upgrade to 1.0.0-rc91 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
RunC allowed additional container processes via 'runc exec' to be ptraced by the pid 1 of the container. This allows the main processes of the container, if running as root, to gain access to file-descriptors of these new processes during the initialization and can lead to container escapes or modification of runC state before the process is fully placed inside the container.
Recommended action: Upgrade to 1.0.0-rc3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In runc, netlink is used internally as a serialization system for specifying the relevant container configuration to the C portion of our code (responsible for the based namespace setup of containers). In all versions of runc prior to 1.0.3, the encoder did not handle the possibility of an integer overflow in the 16-bit length field for the byte array attribute type, meaning that a large enough malicious byte array attribute could result in the length overflowing and the attribute contents being parsed as netlink messages for container configuration. This vulnerability requires the attacker to have some control over the configuration of the container and would allow the attacker to bypass the namespace restrictions of the container by simply adding their own netlink payload which disables all namespaces. Prior to 9c444070ec7bb83995dbc0185da68284da71c554, in practice it was fairly difficult to specify an arbitrary-length netlink message with most container runtimes. The only…
Recommended action: Upgrade to 1.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/opencontainers/runc < 1.0.0-rc9.0.20200122160610-2fc03cc11c77
Fixed in
1.0.0-rc9.0.20200122160610-2fc03cc11c77· Vendor fix available
Issue
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…
Recommended action: Upgrade to 1.0.0-rc9.0.20200122160610-2fc03cc11c77 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
runc 1.0.0-rc94 and earlier are vulnerable to a symlink exchange attack whereby an attacker can request a seemingly-innocuous container configuration that actually results in the host filesystem being bind-mounted into the container (allowing for a container escape). CVE-2021-30465 has been assigned for this issue. An attacker must have the ability to start containers using some kind of custom volume configuration, and while recommended container hardening mechanisms such as LSMs (AppArmor/SELinux) and user namespaces will restrict the amount of damage an attacker could do, they do not block this attack outright. We have a reproducer using Kubernetes (and the below description mentions Kubernetes-specific paths), but this is not a Kubernetes-specific issue. The now-released [runc v1.0.0-rc95][release] contains a fix for this issue, we recommend users update as soon as possible. [release]: https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95 Details In circumstances…
Recommended action: Upgrade to 1.0.0-rc95 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.