{"id":"CVE-2024-45310","aliases":["ALPINE-CVE-2024-45310","AZL-48519","AZL-48525","AZL-48531","AZL-48543","AZL-48555","AZL-48567","AZL-48581","AZL-48590","BELL-CVE-2024-45310","DEBIAN-CVE-2024-45310","EUVD-2024-2819","GHSA-jfvp-7x6p-h2pv","GO-2024-3110","MGASA-2025-0004","OESA-2024-2134","OESA-2024-2135","OESA-2024-2136","OESA-2024-2137","OESA-2024-2253","SUSE-SU-2024:3222-1","SUSE-SU-2024:3324-1","SUSE-SU-2025:02198-1","SUSE-SU-2025:02198-2","SUSE-SU-2025:1374-1","SUSE-SU-2025:20046-1","SUSE-SU-2025:20335-1","SUSE-SU-2025:20353-1","SUSE-SU-2026:0439-1","SUSE-SU-2026:0479-1","SUSE-SU-2026:20551-1","SUSE-SU-2026:20571-1","SUSE-SU-2026:20610-1","UBUNTU-CVE-2024-45310","openSUSE-SU-2024:14312-1","openSUSE-SU-2025:15424-1","openSUSE-SU-2026:10842-1","openSUSE-SU-2026:11153-1","openSUSE-SU-2026:20281-1","openSUSE-SU-2026:20834-1","openSUSE-SU-2026:21265-1","openSUSE-SU-2026:21379-1"],"status":"published","title":"runc can be confused to create empty files/directories on the host","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","severity":{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00317,"percentile":0.24829,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-363","CWE-61"],"published":"2024-09-03T19:07:34Z","modified":"2026-11-05T05:36:30Z","fixes":[{"ecosystem":"Go","package":"github.com/opencontainers/runc","fixed_in":["1.1.14","1.2.0-rc.3"],"sources":["ghsa","osv"]},{"ecosystem":"Alpine:v3.20","package":"runc","fixed_in":["1.1.14-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.21","package":"runc","fixed_in":["1.1.14-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.22","package":"runc","fixed_in":["1.1.14-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.23","package":"runc","fixed_in":["1.1.14-r0"],"sources":["osv"]},{"ecosystem":"Alpine:v3.24","package":"runc","fixed_in":["1.1.14-r0"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"buildah","fixed_in":["1.41.4-2"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"podman","fixed_in":["5.6.1-2"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"runc","fixed_in":["1.2.2-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"moby-runc","fixed_in":["1.1.9-8"],"sources":["osv"]},{"ecosystem":"Alpaquita:23","package":"runc","fixed_in":["1.3.6-r0"],"sources":["osv"]},{"ecosystem":"Alpaquita:stream","package":"runc","fixed_in":["1.1.14-r0"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"runc","fixed_in":["1.1.15+ds1-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"runc","fixed_in":["1.1.15+ds1-1"],"sources":["osv"]},{"ecosystem":"Mageia:9","package":"opencontainers-runc","fixed_in":["1.1.14-1.mga9"],"sources":["osv"]},{"ecosystem":"openEuler:22.03-LTS-SP3","package":"runc","fixed_in":["1.1.3-30.oe2203sp3"],"sources":["osv"]},{"ecosystem":"openEuler:20.03-LTS-SP4","package":"runc","fixed_in":["docker-1.0.0.rc3-228.oe2003sp4"],"sources":["osv"]},{"ecosystem":"openEuler:22.03-LTS-SP1","package":"runc","fixed_in":["docker-1.1.3-30.oe2203sp1"],"sources":["osv"]},{"ecosystem":"openEuler:24.03-LTS","package":"runc","fixed_in":["1.1.8-21.oe2403"],"sources":["osv"]},{"ecosystem":"openEuler:22.03-LTS-SP4","package":"runc","fixed_in":["1.1.3-30.oe2203sp4"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.5","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP5","package":"runc","fixed_in":["1.1.14-150000.70.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP6","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP2-LTSS","package":"runc","fixed_in":["1.1.14-150000.70.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP3-LTSS","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 15 SP2-LTSS","package":"runc","fixed_in":["1.1.14-150000.70.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 15 SP3-LTSS","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP2","package":"runc","fixed_in":["1.1.14-150000.70.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP3","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.1","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Micro 5.2","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Enterprise Storage 7.1","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap Micro 5.5","package":"runc","fixed_in":["1.1.14-150000.70.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.5","package":"runc","fixed_in":["1.1.14-150000.70.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.6","package":"runc","fixed_in":["1.1.14-150000.70.1","1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Containers 12","package":"runc","fixed_in":["1.1.14-16.55.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"runc","fixed_in":["1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"runc","fixed_in":["1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"runc","fixed_in":["1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"runc","fixed_in":["1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP7","package":"runc","fixed_in":["1.2.6-150000.73.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 12 SP5-LTSS","package":"runc","fixed_in":["1.2.6-16.60.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server LTSS Extended Security 12 SP5","package":"runc","fixed_in":["1.2.6-16.60.2"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Micro 6.0","package":"runc","fixed_in":["1.1.14-1.1","1.2.6-1.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Micro 6.1","package":"runc","fixed_in":["1.2.6-slfo.1.1_1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"runc","fixed_in":["1.2.0~rc3-1.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/opencontainers/runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14"}]}]},{"source":"ghsa","ecosystem":"Go","package":"github.com/opencontainers/runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.2.0-rc.1"},{"fixed":"1.2.0-rc.3"}]}]},{"source":"osv","ecosystem":"Alpine:v3.20","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.21","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.22","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.23","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-r0"}]}]},{"source":"osv","ecosystem":"Alpine:v3.24","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-r0"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"buildah","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.41.4-2"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"cri-o","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.30.1-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"podman","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.6.1-2"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.2-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"podman","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"4.1.1-26"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"buildah","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.18.0-29"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"kubernetes","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.28.4-25"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"moby-runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.9-8"}]}]},{"source":"osv","ecosystem":"Alpaquita:23","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.1.4-r3"},{"fixed":"1.3.6-r0"}]}]},{"source":"osv","ecosystem":"Alpaquita:stream","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.1.7-r1"},{"fixed":"1.1.14-r0"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.10+ds1-1","1.1.12+ds1-1","1.1.12+ds1-2","1.1.12+ds1-3","1.1.12+ds1-4","1.1.12+ds1-5","1.1.12+ds1-5.1","1.1.15+ds1-1","1.1.15+ds1-2","1.1.5+ds1-1","1.1.5+ds1-1+deb12u1","1.1.5+ds1-2","1.1.5+ds1-3","1.1.5+ds1-4","1.1.5+ds1-5","1.3.0+ds1-1","1.3.0+ds1-2","1.3.0+ds1-3","1.3.0+ds1-4","1.3.2+ds1-1","1.3.3+ds1-1","1.3.3+ds1-2","1.3.3+ds1-3","1.3.5+ds1-1","1.3.6+ds1-1","1.4.3+ds1-1"]},{"source":"osv","ecosystem":"Debian:13","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.15+ds1-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.15+ds1-1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/opencontainers/runc","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.1.14"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/opencontainers/runc","ranges":[{"type":"SEMVER","events":[{"introduced":"1.2.0-rc.1"},{"fixed":"1.2.0-rc.3"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/opencontainers/runc","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"1.1.14"},{"introduced":"1.2.0-rc.1"},{"fixed":"1.2.0-rc.3"}]}]},{"source":"osv","ecosystem":"Mageia:9","package":"opencontainers-runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-1.mga9"}]}]},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP3","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.3-30.oe2203sp3"}]}]},{"source":"osv","ecosystem":"openEuler:20.03-LTS-SP4","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"docker-1.0.0.rc3-228.oe2003sp4"}]}]},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP1","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"docker-1.1.3-30.oe2203sp1"}]}]},{"source":"osv","ecosystem":"openEuler:24.03-LTS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.8-21.oe2403"}]}]},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.3-30.oe2203sp4"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP6","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP2-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP3-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP2-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP3-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP2","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP3","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.1","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.2","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Enterprise Storage 7.1","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap Micro 5.5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-150000.70.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Containers 12","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-16.55.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP6","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP3-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP3-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP4-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP5-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP3","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP4","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.1","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.2","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Enterprise Storage 7.1","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP7","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-150000.73.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 12 SP5-LTSS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-16.60.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server LTSS Extended Security 12 SP5","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-16.60.2"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Micro 6.0","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.1.14-1.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Micro 6.0","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-1.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Micro 6.1","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.6-slfo.1.1_1.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for HPC 15 SP7","package":"apptainer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.5-150600.4.12.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for HPC 15 SP7","package":"squashfuse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.5.0-150600.3.2.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"apptainer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.5-150600.4.12.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"squashfuse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.5.0-150600.3.2.1"}]}],"bundled":10},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"apptainer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.5-150600.4.12.1"}]}],"bundled":10},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"squashfuse","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.5.0-150600.3.2.1"}]}],"bundled":10},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Containers 15 SP7","package":"kubevirt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.7.0-150700.3.16.2"}]}],"bundled":2},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.0.8+dfsg-2","0.1.1-0ubuntu5~16.04","1.0.0~rc1-0ubuntu1~16.04","1.0.0~rc1-0ubuntu2~16.04.1","1.0.0~rc1-0ubuntu2~16.04.1.1","1.0.0~rc2-0ubuntu2~16.04.1","1.0.0~rc2+docker1.12.6-0ubuntu1~16.04.1","1.0.0~rc2+docker1.13.1-0ubuntu1~16.04.1","1.0.0~rc2+docker1.13.1-0ubuntu1~16.04.2","1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.3","1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.4","1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.4+esm1","1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.4+esm2","1.0.0~rc7+git20190403.029124da-0ubuntu1~16.04.4+esm4"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.0.0~rc2+docker1.13.1-0ubuntu1","1.0.0~rc4+dfsg1-2","1.0.0~rc4+dfsg1-6","1.0.0~rc4+dfsg1-6ubuntu0.18.04.1","1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.1","1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2","1.0.0~rc7+git20190403.029124da-0ubuntu1~18.04.2+esm1","1.0.0~rc10-0ubuntu1~18.04.1","1.0.0~rc10-0ubuntu1~18.04.2","1.0.0~rc93-0ubuntu1~18.04.1","1.0.0~rc93-0ubuntu1~18.04.2","1.0.0~rc95-0ubuntu1~18.04.1","1.0.0~rc95-0ubuntu1~18.04.2","1.0.1-0ubuntu2~18.04.1","1.1.0-0ubuntu1~18.04.1","1.1.4-0ubuntu1~18.04.1","1.1.4-0ubuntu1~18.04.2","1.1.4-0ubuntu1~18.04.2+esm1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.0.0~rc8+git20190923.3e425f80-0ubuntu1","1.0.0~rc10-0ubuntu1","1.0.0~rc93-0ubuntu1~20.04.1","1.0.0~rc93-0ubuntu1~20.04.2","1.0.0~rc95-0ubuntu1~20.04.1","1.0.0~rc95-0ubuntu1~20.04.2","1.0.1-0ubuntu2~20.04.1","1.1.0-0ubuntu1~20.04.1","1.1.0-0ubuntu1~20.04.2","1.1.4-0ubuntu1~20.04.1","1.1.4-0ubuntu1~20.04.2","1.1.4-0ubuntu1~20.04.3","1.1.7-0ubuntu1~20.04.1","1.1.7-0ubuntu1~20.04.2","1.1.7-0ubuntu1~20.04.4","1.1.7-0ubuntu1~20.04.5"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"runc-app","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.12-0ubuntu2~20.04.1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.0.1-0ubuntu2","1.0.1-0ubuntu3","1.0.3-0ubuntu1","1.1.0-0ubuntu1","1.1.0-0ubuntu1.1","1.1.4-0ubuntu1~22.04.1","1.1.4-0ubuntu1~22.04.2","1.1.4-0ubuntu1~22.04.3","1.1.7-0ubuntu1~22.04.1","1.1.7-0ubuntu1~22.04.2","1.1.7-0ubuntu1~22.04.4","1.1.7-0ubuntu1~22.04.5","1.1.7-0ubuntu1~22.04.6"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"runc-app","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.12-0ubuntu2~22.04.1","1.2.5-0ubuntu1~22.04.1","1.3.0-0ubuntu2~22.04.1","1.3.3-0ubuntu1~22.04.2","1.3.3-0ubuntu1~22.04.3","1.3.4-0ubuntu1~22.04.1"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.7-0ubuntu2","1.1.10+ds1-1ubuntu1","1.1.10+ds1-1ubuntu2","1.1.12+ds1-1ubuntu1","1.1.12+ds1-2ubuntu1","1.1.12+ds1-2ubuntu1.1","1.1.12+ds1-2ubuntu1.2","1.1.12+ds1-2ubuntu1.3"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"runc-app","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.10-0ubuntu1","1.1.12-0ubuntu1","1.1.12-0ubuntu2","1.1.12-0ubuntu3","1.1.12-0ubuntu3.1","1.2.5-0ubuntu1~24.04.1","1.3.0-0ubuntu2~24.04.1","1.3.3-0ubuntu1~24.04.2","1.3.3-0ubuntu1~24.04.3","1.3.4-0ubuntu1~24.04.1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"runc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.2.0~rc3-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"govulncheck-vulndb","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.0.20250807T150727-1.1"}]}],"bundled":44},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"apptainer","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.4.5-5.1"}]}],"bundled":6},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"cadvisor","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.60.3-1.1"}]}],"bundled":4},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"cadvisor","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.60.3-bp160.1.1"}]}],"bundled":5},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"ctop","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.7.7-bp160.2.1"}]}],"bundled":5}],"products":[{"vendor":"linuxfoundation","product":"runc"},{"vendor":"opencontainers","product":"runc"}],"references":[{"url":"https://github.com/opencontainers/runc/security/advisories/GHSA-jfvp-7x6p-h2pv","tags":["x_refsource_CONFIRM","Patch","Vendor Advisory","advisory","web","report"]},{"url":"https://github.com/opencontainers/runc/pull/4359","tags":["x_refsource_MISC","Patch","fix","web","report"]},{"url":"https://github.com/opencontainers/runc/commit/63c2908164f3a1daea455bf5bcd8d363d70328c7","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/opencontainers/runc/commit/8781993968fd964ac723ff5f360b6f259e809a3e","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/opencontainers/runc/commit/f0b652ea61ff6750a8fcc69865d45a7abf37accf","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"http://www.openwall.com/lists/oss-security/2024/09/03/1","tags":["Mailing List","Mitigation","Third Party Advisory","web"]},{"url":"https://security.netapp.com/advisory/ntap-20250221-0008/","tags":["Vendor Advisory","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45310","tags":["web","advisory"]},{"url":"https://security.netapp.com/advisory/ntap-20250221-0008","tags":["web"]},{"url":"https://github.com/advisories/GHSA-jfvp-7x6p-h2pv"},{"url":"https://security.alpinelinux.org/vuln/CVE-2024-45310","tags":["advisory"]},{"url":"https://docs.bell-sw.com/security/cves/CVE-2024-45310","tags":["advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/45xxx/CVE-2024-45310.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2024-45310","tags":["advisory"]},{"url":"https://github.com/opencontainers/runc","tags":["package"]},{"url":"https://advisories.mageia.org/MGASA-2025-0004.html","tags":["advisory"]},{"url":"https://bugs.mageia.org/show_bug.cgi?id=33519","tags":["report"]},{"url":"https://www.openwall.com/lists/oss-security/2024/09/03/1","tags":["web","report"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2134","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2135","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2136","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2137","tags":["advisory"]},{"url":"https://www.openeuler.org/en/security/security-bulletins/detail?id=openEuler-SA-2024-2253","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2024/suse-su-20243222-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1230092","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2024-45310","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2024/suse-su-20243324-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502198-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502198-2/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20251374-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202520046-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1192051","tags":["report"]},{"url":"https://bugzilla.suse.com/1214960","tags":["report"]},{"url":"https://bugzilla.suse.com/1221050","tags":["report"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202520335-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202520353-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20260439-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1237608","tags":["report"]},{"url":"https://bugzilla.suse.com/1238611","tags":["report"]},{"url":"https://bugzilla.suse.com/1239322","tags":["report"]},{"url":"https://bugzilla.suse.com/1241710","tags":["report"]},{"url":"https://bugzilla.suse.com/1253506","tags":["report"]},{"url":"https://bugzilla.suse.com/1253784","tags":["report"]},{"url":"https://bugzilla.suse.com/1253967","tags":["report"]},{"url":"https://bugzilla.suse.com/1255462","tags":["report"]},{"url":"https://bugzilla.suse.com/1257432","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22869","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22870","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22872","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-27144","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47913","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47914","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-58181","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-65105","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-8556","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20260479-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1253189","tags":["report"]},{"url":"https://bugzilla.suse.com/1257128","tags":["report"]},{"url":"https://bugzilla.suse.com/1257422","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64435","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202620551-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1241772","tags":["report"]},{"url":"https://bugzilla.suse.com/1253181","tags":["report"]},{"url":"https://bugzilla.suse.com/1253185","tags":["report"]},{"url":"https://bugzilla.suse.com/1253186","tags":["report"]},{"url":"https://bugzilla.suse.com/1253194","tags":["report"]},{"url":"https://bugzilla.suse.com/1253748","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64324","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64432","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64433","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64434","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-64437","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202620571-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202620610-1/","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2024-45310","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-45310","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2015-7561","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2016-9962","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-1000056","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2017-1002102","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-1002100","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-1002101","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-16733","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2018-19184","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-1002100","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-1002101","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-11245","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-11251","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2019-11253","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-26240","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-26241","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8551","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8555","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8557","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8558","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8562","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8563","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2020-8566","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-25735","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-25736","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-25737","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-25741","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-25743","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2021-30465","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-29162","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-29177","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-3162","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2022-3294","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-2431","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-25809","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-2727","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-2728","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-27561","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-28642","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2023-5528","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-5321","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-3445","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47907","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-47908","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-33814","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39827","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39831","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39832","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39835","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-10722","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-33186","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39821","tags":["web"]},{"url":"https://bugzilla.suse.com/1265844","tags":["report"]},{"url":"https://bugzilla.suse.com/1266202","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39828","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39829","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39830","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39833","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-39834","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42508","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46595","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46597","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-46598","tags":["web"]},{"url":"https://bugzilla.suse.com/1239291","tags":["report"]},{"url":"https://bugzilla.suse.com/1257429","tags":["report"]},{"url":"https://bugzilla.suse.com/1260305","tags":["report"]},{"url":"https://bugzilla.suse.com/1266645","tags":["report"]},{"url":"https://bugzilla.suse.com/1267788","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-22868","tags":["web"]},{"url":"https://bugzilla.suse.com/1248710","tags":["report"]},{"url":"https://bugzilla.suse.com/1257431","tags":["report"]},{"url":"https://bugzilla.suse.com/1265800","tags":["report"]},{"url":"https://bugzilla.suse.com/1266632","tags":["report"]},{"url":"https://bugzilla.suse.com/1267805","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2022-21698","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2024-45310","title":"runc can be confused to create empty files/directories on the host","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:07:34.06Z","modified":"2025-02-21T18:03:30.271Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low","assessor":"cna"}],"cwes":["CWE-363","CWE-61"],"updated_at":"2026-11-02T14:34:08.16279Z"}],"euvd":[{"id":"EUVD-2024-2819","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:07:34Z","modified":"2025-02-21T18:03:30Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T20:53:25.922377Z"}],"ghsa":[{"id":"GHSA-jfvp-7x6p-h2pv","title":"runc can be confused to create empty files/directories on the host","description":"### Impact\nrunc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into\ncreating empty files or directories in arbitrary locations in the host\nfilesystem by sharing a volume between two containers and exploiting a race\nwith os.MkdirAll. While this can be used to create empty files, existing\nfiles **will not** be truncated.\n\nAn attacker must have the ability to start containers using some kind of custom\nvolume configuration. Containers using user namespaces are still affected, but\nthe scope of places an attacker can create inodes can be significantly reduced.\nSufficiently strict LSM policies (SELinux/Apparmor) can also in principle block\nthis attack -- we suspect the industry standard SELinux policy may restrict\nthis attack's scope but the exact scope of protection hasn't been analysed.\n\nThis is exploitable using runc directly as well as through Docker and\nKubernetes.\n\nThe CVSS score for this vulnerability is\nCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).\n\n### Workarounds\nUsing user namespaces restricts this attack fairly significantly such that the\nattacker can only create inodes in directories that the remapped root\nuser/group has write access to. Unless the root user is remapped to an actual\nuser on the host (such as with rootless containers that don't use\n/etc/sub[ug]id), this in practice means that an attacker would only be able to\ncreate inodes in world-writable directories.\n\nA strict enough SELinux or AppArmor policy could in principle also restrict the\nscope if a specific label is applied to the runc runtime, though we haven't\nthoroughly tested to what extent the standard existing policies block this\nattack nor what exact policies are needed to sufficiently restrict this attack.\n\n### Patches\nFixed in runc v1.1.14 and v1.2.0-rc3.\n\n* `main` patches:\n  * https://github.com/opencontainers/runc/pull/4359\n  *  https://github.com/opencontainers/runc/commit/63c2908164f3a1daea455bf5bcd8d363d70328c7\n* `release-1.1` patches:\n  * https://github.com/opencontainers/runc/commit/8781993968fd964ac723ff5f360b6f259e809a3e\n  * https://github.com/opencontainers/runc/commit/f0b652ea61ff6750a8fcc69865d45a7abf37accf\n\n### Credits\nThanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from\nMicrosoft for discovering and reporting this vulnerability.","status":"published","published":"2024-09-03T19:49:32Z","modified":"2025-02-21T21:03:05Z","cvss":[{"version":"4.0","score":4.8,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/U:Green","level":"medium"},{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"cwes":["CWE-61","CWE-363"],"updated_at":"2026-11-02T14:38:32.275316Z"}],"nvd":[{"id":"CVE-2024-45310","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15.243Z","modified":"2026-06-17T07:54:00.017Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low","assessor":"secondary"},{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low","assessor":"primary"}],"cwes":["CWE-61","CWE-363"],"updated_at":"2026-11-02T14:10:24.514378Z"}],"osv":[{"id":"ALPINE-CVE-2024-45310","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15.243Z","modified":"2026-11-03T06:32:49.93469767Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-03T07:16:46.202932Z"},{"id":"BELL-CVE-2024-45310","status":"published","published":"2024-09-04T05:57:30.73672Z","modified":"2026-06-20T07:15:04.855472175Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:28:20.452786Z"},{"id":"CVE-2024-45310","title":"runc can be confused to create empty files/directories on the host","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:07:34.06Z","modified":"2026-10-28T19:12:18.394198842Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"cwes":["CWE-363","CWE-61"],"updated_at":"2026-11-02T15:44:42.790566Z"},{"id":"DEBIAN-CVE-2024-45310","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.  Some workarounds are available. 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15.243Z","modified":"2026-11-02T12:03:01.027896633Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:45:43.473331Z"},{"id":"GHSA-jfvp-7x6p-h2pv","title":"runc can be confused to create empty files/directories on the host","description":"### Impact\nrunc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into\ncreating empty files or directories in arbitrary locations in the host\nfilesystem by sharing a volume between two containers and exploiting a race\nwith os.MkdirAll. While this can be used to create empty files, existing\nfiles **will not** be truncated.\n\nAn attacker must have the ability to start containers using some kind of custom\nvolume configuration. Containers using user namespaces are still affected, but\nthe scope of places an attacker can create inodes can be significantly reduced.\nSufficiently strict LSM policies (SELinux/Apparmor) can also in principle block\nthis attack -- we suspect the industry standard SELinux policy may restrict\nthis attack's scope but the exact scope of protection hasn't been analysed.\n\nThis is exploitable using runc directly as well as through Docker and\nKubernetes.\n\nThe CVSS score for this vulnerability is\nCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).\n\n### Workarounds\nUsing user namespaces restricts this attack fairly significantly such that the\nattacker can only create inodes in directories that the remapped root\nuser/group has write access to. Unless the root user is remapped to an actual\nuser on the host (such as with rootless containers that don't use\n/etc/sub[ug]id), this in practice means that an attacker would only be able to\ncreate inodes in world-writable directories.\n\nA strict enough SELinux or AppArmor policy could in principle also restrict the\nscope if a specific label is applied to the runc runtime, though we haven't\nthoroughly tested to what extent the standard existing policies block this\nattack nor what exact policies are needed to sufficiently restrict this attack.\n\n### Patches\nFixed in runc v1.1.14 and v1.2.0-rc3.\n\n* `main` patches:\n  * https://github.com/opencontainers/runc/pull/4359\n  *  https://github.com/opencontainers/runc/commit/63c2908164f3a1daea455bf5bcd8d363d70328c7\n* `release-1.1` patches:\n  * https://github.com/opencontainers/runc/commit/8781993968fd964ac723ff5f360b6f259e809a3e\n  * https://github.com/opencontainers/runc/commit/f0b652ea61ff6750a8fcc69865d45a7abf37accf\n\n### Credits\nThanks to Rodrigo Campos Catelin (@rata) and Alban Crequy (@alban) from\nMicrosoft for discovering and reporting this vulnerability.","status":"published","published":"2024-09-03T19:49:32Z","modified":"2026-09-10T03:50:18.280094459Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"},{"version":"4.0","score":4.8,"vector":"CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N/U:Green","level":"medium"}],"cwes":["CWE-363","CWE-61"],"updated_at":"2026-11-02T15:46:50.336262Z"},{"id":"OESA-2024-2134","title":"runc security update","description":"runc is a CLI tool for spawning and running containers according to the OCI specification.\r\n\r\nSecurity Fix(es):\r\n\r\nrunc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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\u0026apos;s scope but the exact scope of protection hasn\u0026apos;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.\r\n\r\nSome workarounds are available. 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\nuser on the host (such as with rootless containers that don\u0026apos;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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.(CVE-2024-45310)","status":"published","published":"2024-09-14T11:07:36Z","modified":"2026-08-18T01:17:32.891652918Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2135","title":"runc security update","description":"runc is a CLI tool for spawning and running containers according to the OCI specification.\r\n\r\nSecurity Fix(es):\r\n\r\nrunc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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\u0026apos;s scope but the exact scope of protection hasn\u0026apos;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.\r\n\r\nSome workarounds are available. 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\nuser on the host (such as with rootless containers that don\u0026apos;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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.(CVE-2024-45310)","status":"published","published":"2024-09-14T11:07:36Z","modified":"2026-08-18T01:17:32.681998665Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2136","title":"runc security update","description":"runc is a CLI tool for spawning and running containers according to the OCI specification.\r\n\r\nSecurity Fix(es):\r\n\r\nrunc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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\u0026apos;s scope but the exact scope of protection hasn\u0026apos;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.\r\n\r\nSome workarounds are available. 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\nuser on the host (such as with rootless containers that don\u0026apos;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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.(CVE-2024-45310)","status":"published","published":"2024-09-14T11:07:36Z","modified":"2026-08-18T01:17:32.842931653Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2137","title":"runc security update","description":"runc is a CLI tool for spawning and running containers according to the OCI specification.\r\n\r\nSecurity Fix(es):\r\n\r\nrunc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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\u0026apos;s scope but the exact scope of protection hasn\u0026apos;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.\r\n\r\nSome workarounds are available. 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\nuser on the host (such as with rootless containers that don\u0026apos;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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.(CVE-2024-45310)","status":"published","published":"2024-09-14T11:07:36Z","modified":"2026-08-18T01:17:32.851170532Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"OESA-2024-2253","title":"runc security update","description":"runc is a CLI tool for spawning and running containers according to the OCI specification.\n\nSecurity Fix(es):\n\nrunc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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\u0026apos;s scope but the exact scope of protection hasn\u0026apos;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser on the host (such as with rootless containers that don\u0026apos;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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.(CVE-2024-45310)","status":"published","published":"2024-10-12T11:07:43Z","modified":"2026-08-18T01:17:34.426605731Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T15:52:41.595342Z"},{"id":"UBUNTU-CVE-2024-45310","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3. Some workarounds are available. 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:00Z","modified":"2026-04-08T14:40:27.414459Z","cvss":[{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"},{"version":"3.1","score":3.6,"vector":"CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N","level":"low"}],"updated_at":"2026-11-02T16:55:02.636559Z"},{"id":"AZL-48519","title":"CVE-2024-45310 affecting package buildah for versions less than 1.41.4-2","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:52:51.646546Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48525","title":"CVE-2024-45310 affecting package cri-o 1.30.1-1","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-11-05T05:36:30Z","updated_at":"2026-11-05T16:41:20.514083Z"},{"id":"AZL-48531","title":"CVE-2024-45310 affecting package podman for versions less than 5.6.1-2","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:55:55.809333Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48543","title":"CVE-2024-45310 affecting package runc for versions less than 1.2.2-1","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:55:06.417054Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48555","title":"CVE-2024-45310 affecting package podman 4.1.1-26","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:33:03.048386Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48567","title":"CVE-2024-45310 affecting package buildah 1.18.0-29","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:33:03.344399Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48581","title":"CVE-2024-45310 affecting package kubernetes 1.28.4-25","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:33:03.264755Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48590","title":"CVE-2024-45310 affecting package moby-runc for versions less than 1.1.9-8","description":"runc is a CLI tool for spawning and running containers according to the OCI specification. 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 could be used to create empty files, existing files would 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 issue is fixed in runc v1.1.14 and v1.2.0-rc3.\n\nSome workarounds are available. 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\nuser 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 neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.","status":"published","published":"2024-09-03T19:15:15Z","modified":"2026-04-21T04:33:03.494319Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"GO-2024-3110","title":"Can be confused to create empty files/directories on the host in github.com/opencontainers/runc","description":"Can be confused to create empty files/directories on the host in github.com/opencontainers/runc","status":"published","published":"2024-09-06T20:43:50Z","modified":"2026-02-04T02:23:26.560077Z","updated_at":"2026-11-02T15:47:01.453823Z"},{"id":"MGASA-2025-0004","title":"Updated opencontainers-runc packages fix security vulnerability","description":"runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into\ncreating empty files or directories in arbitrary locations in the host\nfilesystem by sharing a volume between two containers and exploiting a race\nwith os.MkdirAll. While this can be used to create empty files, existing\nfiles **will not** be truncated.  An attacker must have the ability to start\ncontainers using some kind of custom volume configuration. Containers using\nuser namespaces are still affected, but the scope of places an attacker can\ncreate inodes can be significantly reduced.  Sufficiently strict LSM policies\n(SELinux/Apparmor) can also in principle block this attack -- we suspect the\nindustry standard SELinux policy may restrict this attack's scope but the\nexact scope of protection hasn't been analysed.  This is exploitable using\nrunc directly as well as through Docker and Kubernetes.\n","status":"published","published":"2025-01-10T19:54:34Z","modified":"2026-04-16T04:44:26.070332544Z","updated_at":"2026-11-02T15:49:42.684501Z"},{"id":"openSUSE-SU-2024:14312-1","title":"runc-1.2.0~rc3-1.1 on GA media","description":"These are all security issues fixed in the runc-1.2.0~rc3-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-09-04T00:00:00Z","modified":"2026-02-04T03:53:31.215117Z","updated_at":"2026-11-02T16:58:36.662953Z"},{"id":"openSUSE-SU-2025:15424-1","title":"govulncheck-vulndb-0.0.20250807T150727-1.1 on GA media","description":"These are all security issues fixed in the govulncheck-vulndb-0.0.20250807T150727-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-08-08T00:00:00Z","modified":"2026-03-23T04:53:45.821911Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"openSUSE-SU-2026:10842-1","title":"apptainer-1.4.5-5.1 on GA media","description":"These are all security issues fixed in the apptainer-1.4.5-5.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-05-23T00:00:00Z","modified":"2026-05-24T13:30:05.209575093Z","updated_at":"2026-11-02T16:58:38.415593Z"},{"id":"openSUSE-SU-2026:11153-1","title":"cadvisor-0.60.3-1.1 on GA media","description":"These are all security issues fixed in the cadvisor-0.60.3-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-06-30T00:00:00Z","modified":"2026-07-01T09:45:07.378282527Z","updated_at":"2026-11-02T16:58:38.95195Z"},{"id":"openSUSE-SU-2026:20281-1","title":"Security update for kubevirt","description":"This update for kubevirt fixes the following issues:\n\nUpdate to version 1.7.0 (bsc#1257128).\n\nSecurity issues fixed:\n\n  - CVE-2025-64435: logic flaw in the virt-controller can lead to incorrect status updates and potentially causing a DoS\n    (bsc#1253189).\n  - CVE-2024-45310: kubevirt vendored github.com/opencontainers/runc/libcontainer/utils: runc can be tricked into\n    creating empty files/directories on host (bsc#1257422).\n  - CVE-2025-22872: incorrectly interpreted tags can cause content to be placed wrong scope during DOM construction\n    (bsc#1241772).\n  - CVE-2025-64432: fail to correctly validate certain fields in the client TLS certificate may allow an attacker to\n    bypass existing RBAC controls (bsc#1253181).\n  - CVE-2025-64433: improper symlink handling can allow to read arbitrary files (bsc#1253185).\n  - CVE-2025-64434: compromising virt-handler instance can lead to impersonate virt-api and execute privileged operations\n    (bsc#1253186).\n  - CVE-2025-64437: mishandling of symlinks can lead to compromising the CIA (bsc#1253194).\n  - CVE-2025-64324: a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users\n    (bsc#1253748).\n\nOther updates and bugfixes:\n\n  - Upstream now uses stateless firmware for CoCo VMs.\n","status":"withdrawn","published":"2026-02-27T08:51:11Z","modified":"2026-10-24T13:00:08.679113823Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"openSUSE-SU-2026:20834-1","title":"Security update for apptainer","description":"This update for apptainer fixes the following issues:\n\nChanges in apptainer:\n\n- Fix CVE-2026-39827, CVE-2026-39834, CVE-2026-39828, CVE-2026-39829,\n  CVE-2026-39831, CVE-2026-42508, CVE-2026-39833, CVE-2026-39830,\n  CVE-2026-39832, CVE-2026-46597, CVE-2026-46598, CVE-2026-46595,\n  CVE-2026-39835 (bsc#1266202)\n  Update golang.org/x/crypto to v0.52.0\n\n- Fix  CVE-2026-33814 GO-2026-4918 (bsc#1265844)\n  Update golang.org/x/net to version v0.53.0\n- Integrate vulnchecker into %check stage (optional).\n\n- Sync with Factory version which also fixes CVE-2024-45310\n  tracked in bsc#1257432\n- Readded SLE-15SP6.def as it was removed from Factory\n","status":"published","published":"2026-05-28T12:23:45Z","modified":"2026-05-31T18:24:29.626707993Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"openSUSE-SU-2026:21265-1","title":"Security update for cadvisor","description":"This update for cadvisor fixes the following issues:\n\nChanges in cadvisor:\n\n- update to 0.60.3:\n  * Move OOM watching out of the lib module into the binary\n  * lib/model: make ContainerStats sub-stats pointers to convey\n    collection presence\n- update to 0.60.1:\n  * cpuload/netlink: report the real error and skip the reader on\n    cgroup v2\n  * deploy: add lib/go.mod to the image build's dependency cache\n- update to 0.60.0:\n  * Exposing additional cgroup v2 memory.stat metrics\n  * lib: introduce github.com/google/cadvisor/lib — a lean,\n    kubelet-focused library module\n- bump x/net to 0.55 (bsc#1266645, CVE-2026-39821)\n\n- update to 0.57.0 (bsc#1260305, CVE-2026-33186):\n  * integration: add more Docker container handler tests\n  * integration: add containerd container handler tests\n  * integration: add Prometheus metrics endpoint tests\n  * fix: support podman `volatile-containers.json` and/or\n    `containers.json`\n  * proposed roadmap for cAdvisor\n  * remove log message when you can't read productName\n  * Refactor Github Action per b/485167538\n  * fix crio deadlock in getting crio sandbox containers\n  * Add container_creation_time_seconds (previously:\n    container_start_time_seconds); use runtime start time for\n    container_start_time_seconds (podman \u0026 docker)\n  * deps: github.com/moby/moby/client v0.4.0, moby/api v1.54.1,\n    containerd/ttrpc v1.2.8\n  * fix(build): update k8s-staging-test-infra image in integ\n    tests\n  * feat(manager/container): add configurable initial splay and\n    max jitter factors\n  * feat(manager): add constraint data in OOM events\n  * fix: add v-prefixed GHCR image tags for release consistency\n  * build(deps): bump the go_modules group across 2 directories\n    with 1 update\n  * Expose cgroup v2 memory.events as Prometheus metrics\n  * deploy: bump base images to Alpine 3.23\n\n- Update to version 0.56.2:\n  * docker: fix nil pointer dereference when GraphDriver is nil\n  * Update healthcheck.sh\n  * Update entrypoint.sh\n  * docker: migrate to github.com/moby/moby modules\n  * Update containerd, docker, moby, and opencontainers dependencies\n  * update README\n  * Update copyright year in healthcheck.sh\n  * Update copyright year in entrypoint.sh\n  * Added cadvisor boilerplate header to deploy/entrypoint.sh\n  * Added cadvisor boilerplate header to deploy/healthcheck.sh\n  * Add EXPOSE 8080 to document default port\n  * Fix healthcheck to respect custom port flag\n  * Add entrypoint wrapper to preserve -logtostderr flag\n  * add std in summary\n  * fix formatting\n  * Update container/docker/factory.go\n  * Update factory.go\n  * Update factory.go\n  * Update factory.go\n  * Fix for issue #3772\n  * docs: replace references to docker registry `gcr.io` with `ghcr.io`\n  * Expose s390x CPU Topology to Prometheus\n\n- update to 0.55.1:\n  * manager: fix race condition in Stop() using sync.Once\n  * manager: fix race condition in Stop() using sync.Once\n- update to 0.55.0:\n  * Reduce lock contention in manager package\n  * container/podman: fix `zfsFilesystem` and `zfsParent` being\n    swapped.\n  * devicemapper: use atomic.Value for lock-free cache reads\n  * Reduce lock contention in cache/memory package\n  * zfs: use atomic.Value for lock-free cache reads\n  * fix: docker health check status not updating\n  * align docker and podman implementations\n  * disable CGO for fully static binaries\n  * close stale PRs and Issues\n  * refactor(container): Migrate to std lib context package\n  * add workflow_dispatch to stale github action\n  * plugin factory: remove useless RegisterPlugin log output\n  * feat(summary): add count in percentiles\n  * machine: fixes for unix.Uname use\n  * feat: add LoadTaskProcess api in containerd client\n  * feat: add exit code in container deletion events\n  * feat: add CRI-O integration tests\n  * test: reorganize integration tests and add CRI-O test\n    coverage\n  * refactor: remove duplicate tests from api package and add\n    missing CRI-O tests\n  * fix: update golang.org/x/crypto to v0.45.0 to fix security\n    vulnerabilities\n  * container/(docker|podman): rewrite obtaining IP-address\n  * Upgrade GitHub Actions to latest versions\n  * Upgrade GitHub Actions for Node 24 compatibility\n  * feat: add fs io cost metrics\n  * go.mod: github.com/docker/go-connections v0.6.0\n  * fs: introduce pluggable filesystem architecture\n  * Apply build tags liberally for supported environments (linux)\n  * Replace godirwalk with os.ReadDir from standard library\n  * feat: add cpu burst metrics\n- update to 0.54.1:\n  * chore: update cAdvisor image registry and version in\n    DaemonSet\n  * ci: update Ubuntu version to 24.04 in GitHub Actions\n    workflows\n  * chore: re-enable golangci-lint checks and fix violations\n  * container/docker: GetStats: prevent nil-pointer\n- update to 0.54.0:\n  * Let us try to use ghcr.io for container images\n  * Add a GH action to create release binaries\n  * use qemu/docker to build arch specific binaries\n  * add -buildvcs=false to GH action\n  * fix(3643) add containerd-snapshotter support\n  * Update README.md with latest Docker image version and\n    registry\n  * Rebase to alpine 3.22, install thin-provisioning-tools from\n    main repo\n  * feat: add metric for container health check status  (DOCKER-\n    Specific!)\n  * Update golang and deps\n- update to version 0.54.1:\n  * container/docker: GetStats: prevent nil-pointer\n  * chore: re-enable golangci-lint checks and fix violations\n  * fix: use Docker-embedded containerd socket in integration tests\n  * refactor: remove Mesos container support\n  * ci: add diagnostic logging for docker/containerd debugging\n  * fix: persist containerd client error to prevent nil pointer dereference\n  * ci: update Ubuntu version to 24.04 in GitHub Actions workflows\n  * chore: update cAdvisor image registry and version in DaemonSet\n  * fix: handle nil Health state in docker container handler\n  * ci: update Go version to 1.25 in GitHub Actions workflows\n  * fix: update dependencies to address security vulnerabilities\n  * add health status tests\n  * feat: Update docker container handler to include health status in stats\n  * Rebase to alpine 3.22, install thin-provisioning-tools from main repo\n  * Update README.md Docker image reference\n  * fix(3643) add containerd-snapshotter support\n  * add -buildvcs=false to GH action\n  * use qemu/docker to build arch specific binaries\n  * Add a GH action to create release binaries\n  * Let us try to use ghcr.io for container images (#3699)\n\n- update to 0.53.0 (bsc#1257429, CVE-2024-45310,\n    bsc#1267788, CVE-2026-10722):\n  * fix potential hang on containerd client.LoadContainer\n  * Bump dependencies to latest (June 2, 2025)\n  * fix: fix call Errorf with wrong err\n  * Fixed possible data race\n  * Use built-in error wrapping instead of pkg/errors\n\n- update to 0.52.1:\n  * Make resctrl optional/pluggable\n- update to 0.52.0:\n  * bump containerd related deps: api v1.8.0; errdefs v1.0.0;\n    ttrpc v1.2.6\n  * chore: Update Prometheus libraries\n  * ci: golangci-lint bump, fixes, and cleanups\n  * bump runc to v1.2.4\n  * Add Pressure Stall Information Metrics\n  * Switch to opencontainers/cgroups repository (includes update\n    from golang 1.22 to 1.24)\n  * Bump to newer opencontainers/image-spec @ v1.1.1\n- update to 0.49.2:\n  * Cp fix test\n  * Revert \"reduce_logs_for_kubelet_use_crio\"\n","status":"published","published":"2026-07-06T16:05:20Z","modified":"2026-07-09T10:00:12.24593618Z","updated_at":"2026-11-02T16:58:41.885092Z"},{"id":"openSUSE-SU-2026:21379-1","title":"Security update for ctop","description":"This update for ctop fixes the following issues:\n\nChanges in ctop embedded dependencies:\n\n- CVE-2022-21698: client_golang: Denial of service using InstrumentHandlerCounter (bsc#1248710)\n- CVE-2024-45310: runc: runc can be tricked into creating empty files (bsc#1257431)\n- CVE-2026-10722: ebpf: Crash when parsing malformed ELF/BTF input (bsc#1267805)\n- CVE-2026-33814: net: Infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265800)\n- CVE-2026-39821: net: Failure to reject ASCII-only Punycode-encoded labels (bsc#1266632)\n","status":"published","published":"2026-07-18T19:25:19Z","modified":"2026-07-22T18:25:11.652124971Z","updated_at":"2026-11-02T16:58:41.885092Z"},{"id":"SUSE-SU-2024:3222-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n\n- Update to runc v1.1.14\n- CVE-2024-45310: Fixed an issue where runc can be tricked into creating empty files/directories on host. (bsc#1230092)\n  ","status":"published","published":"2024-09-12T11:21:15Z","modified":"2026-02-04T02:25:09.669029Z","updated_at":"2026-11-02T15:53:55.639015Z"},{"id":"SUSE-SU-2024:3324-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n\n- Update to runc v1.1.14\n- CVE-2024-45310: Fixed an issue where runc can be tricked into creating empty files/directories on host. (bsc#1230092)\n  ","status":"published","published":"2024-09-19T06:52:10Z","modified":"2025-05-02T04:37:04.902182Z","updated_at":"2026-11-02T15:53:55.639015Z"},{"id":"SUSE-SU-2025:02198-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n  \n- CVE-2024-45310: Fixed unintentional creation of empty files/directories on host (bsc#1230092)\n\nOther fixes:\n\n- Update to runc v1.2.6.\n","status":"published","published":"2025-07-02T09:22:54Z","modified":"2026-03-23T04:48:31.714595Z","updated_at":"2026-11-02T15:53:56.647031Z"},{"id":"SUSE-SU-2025:02198-2","title":"Security update for runc","description":"This update for runc fixes the following issues:\n  \n- CVE-2024-45310: Fixed unintentional creation of empty files/directories on host (bsc#1230092)\n\nOther fixes:\n\n- Update to runc v1.2.6.\n","status":"published","published":"2025-07-16T09:09:00Z","modified":"2026-02-04T04:39:46.860599Z","updated_at":"2026-11-02T15:53:56.647031Z"},{"id":"SUSE-SU-2025:1374-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n\n- CVE-2024-45310: Fixed unintentional creation of empty files/directories on host (bsc#1230092)\n\nOther fixes:\n\n- Update to runc v1.2.6.\n","status":"published","published":"2025-04-25T12:39:27Z","modified":"2026-02-04T03:37:51.869239Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2025:20046-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n\nUpdate to runc v1.1.14. Upstream changelog is available from\n  \u003chttps://github.com/opencontainers/runc/releases/tag/v1.1.14\u003e.\n\n- CVE-2024-45310: Fixed that runc can be tricked into creating empty files/directories on host ( bsc#1230092)\n\nUpdate to runc v1.1.13. Upstream changelog is available from\n  \u003chttps://github.com/opencontainers/runc/releases/tag/v1.1.13\u003e.\n\n- Fixed a performance issue when running lots of containers, caused by systemd getting\n  too many mount notifications. bsc#1214960\n- Fixed -ENOSYS stub on ppc64le. bsc#1192051 bsc#1221050\n","status":"published","published":"2025-02-03T08:55:05Z","modified":"2026-03-23T04:50:41.174346Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2025:20335-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n\n- Update to runc v1.2.6. Upstream changelog is available from\n\n  https://github.com/opencontainers/runc/releases/tag/v1.2.6\n\n- CVE-2024-45310: Fixed runc can be tricked into creating empty files/directories on host (bsc#1230092)\n\n","status":"published","published":"2025-05-21T15:39:04Z","modified":"2026-03-23T04:50:06.896979Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2025:20353-1","title":"Security update for runc","description":"This update for runc fixes the following issues:\n\nUpdate to runc v1.2.6. Upstream changelog is available from\n  \u003chttps://github.com/opencontainers/runc/releases/tag/v1.2.6\u003e.\n\nUpdate to runc v1.2.0~rc3. Upstream changelog is available from\n\n  \u003chttps://github.com/opencontainers/runc/releases/tag/v1.2.0-rc.3\u003e.\n\n- CVE-2024-45310: Fixed that runc can be tricked into creating empty files/directories on host (bsc#1230092)\n\n","status":"published","published":"2025-05-21T11:11:43Z","modified":"2026-03-23T04:50:47.46998Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2026:0439-1","title":"Security update for apptainer","description":"This update for apptainer fixes the following issues:\n\nSecurity fixes:\n\n- CVE-2024-45310: Fixed runc being tricked into creating empty \n  files/directories on host (bsc#1257432)\n- CVE-2025-65105: Fixed security bypass due to disabling security \n  options (bsc#1255462)\n- CVE-2025-47914: Fixed malformed constraint may cause denial of \n  service in golang.org/x/crypto/ssh/agent (bsc#1253967)\n- CVE-2025-58181: Fixed unbounded memory consumption in \n  golang.org/x/crypto/ssh (bsc#1253784)\n- CVE-2025-47913: Fixed potential denial of service in \n  golang.org/x/crypto/ssh/agent (bsc#1253506)\n- CVE-2025-22872: Fixed incorrect Neutralization of Input During \n  Web Page Generation in x/net (bsc#1241710)\n- CVE-2025-22870: Fixed HTTP Proxy bypass using IPv6 Zone IDs in \n  golang.org/x/net (bsc#1238611)\n- CVE-2025-22869: Fixed potential denial of service in \n  golang.org/x/crypto (bsc#1239322)\n- CVE-2025-27144: Fixed DoS in go-jose Parsing in \n  github.com/go-jose/go-jose (bsc#1237608)\n- CVE-2025-8556: Fixed missing and wrong validation can lead \n  to incorrect results in github.com/cloudflare/circl\n\nOther fixes:\n\n- Update to 1.4.5\n","status":"published","published":"2026-02-11T09:30:02Z","modified":"2026-03-23T04:52:14.592142Z","updated_at":"2026-11-02T15:54:00.846737Z"},{"id":"SUSE-SU-2026:0479-1","title":"Security update for kubevirt, virt-api-container, virt-controller-container, virt-exportproxy-container, virt-exportserver-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container, virt-pr-helper-container, virt-synchronization-controller-container","description":"This update for kubevirt, virt-api-container, virt-controller-container, virt-exportproxy-container, virt-exportserver-container, virt-handler-container, virt-launcher-container, virt-libguestfs-tools-container, virt-operator-container, virt-pr-helper-container, virt-synchronization-controller-container fixes the following issues:\n\nUpdate to version 1.7.0. (bsc#1257128)\n\n  Release notes https://github.com/kubevirt/kubevirt/releases/tag/v1.7.0\n\n- CVE-2025-64435: Fixes logic flaw in the virt-controller can lead to incorrect status updates and potentially causing a DoS (bsc#1253189 )\n- CVE-2024-45310: Fixes kubevirt vendored github.com/opencontainers/runc/libcontainer/utils: runc can be tricked into creating empty files/directories on host bsc#1257422 \n\n- Upstream now uses stateless firmware for CoCo VMs.\n","status":"published","published":"2026-02-12T15:34:08Z","modified":"2026-02-13T16:58:53.391596Z","updated_at":"2026-11-02T15:54:00.846737Z"},{"id":"SUSE-SU-2026:20551-1","title":"Security update for kubevirt","description":"This update for kubevirt fixes the following issues:\n\nUpdate to version 1.7.0 (bsc#1257128).\n\nSecurity issues fixed:\n\n  - CVE-2025-64435: logic flaw in the virt-controller can lead to incorrect status updates and potentially causing a DoS\n    (bsc#1253189).\n  - CVE-2024-45310: kubevirt vendored github.com/opencontainers/runc/libcontainer/utils: runc can be tricked into\n    creating empty files/directories on host (bsc#1257422).\n  - CVE-2025-22872: incorrectly interpreted tags can cause content to be placed wrong scope during DOM construction\n    (bsc#1241772).\n  - CVE-2025-64432: fail to correctly validate certain fields in the client TLS certificate may allow an attacker to\n    bypass existing RBAC controls (bsc#1253181).\n  - CVE-2025-64433: improper symlink handling can allow to read arbitrary files (bsc#1253185).\n  - CVE-2025-64434: compromising virt-handler instance can lead to impersonate virt-api and execute privileged operations\n    (bsc#1253186).\n  - CVE-2025-64437: mishandling of symlinks can lead to compromising the CIA (bsc#1253194).\n  - CVE-2025-64324: a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users\n    (bsc#1253748).\n\nOther updates and bugfixes:\n\n  - Upstream now uses stateless firmware for CoCo VMs.\n","status":"withdrawn","published":"2026-02-27T08:49:48Z","modified":"2026-10-28T19:00:08.746480783Z","updated_at":"2026-11-02T15:54:01.953589Z"},{"id":"SUSE-SU-2026:20571-1","title":"Security update for kubevirt","description":"This update for kubevirt fixes the following issues:\n\nUpdate to version 1.7.0 (bsc#1257128).\n\nSecurity issues fixed:\n\n  - CVE-2025-64435: logic flaw in the virt-controller can lead to incorrect status updates and potentially causing a DoS\n    (bsc#1253189).\n  - CVE-2024-45310: kubevirt vendored github.com/opencontainers/runc/libcontainer/utils: runc can be tricked into\n    creating empty files/directories on host (bsc#1257422).\n  - CVE-2025-22872: incorrectly interpreted tags can cause content to be placed wrong scope during DOM construction\n    (bsc#1241772).\n  - CVE-2025-64432: fail to correctly validate certain fields in the client TLS certificate may allow an attacker to\n    bypass existing RBAC controls (bsc#1253181).\n  - CVE-2025-64433: improper symlink handling can allow to read arbitrary files (bsc#1253185).\n  - CVE-2025-64434: compromising virt-handler instance can lead to impersonate virt-api and execute privileged operations\n    (bsc#1253186).\n  - CVE-2025-64437: mishandling of symlinks can lead to compromising the CIA (bsc#1253194).\n  - CVE-2025-64324: a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users\n    (bsc#1253748).\n\nOther updates and bugfixes:\n\n  - Upstream now uses stateless firmware for CoCo VMs.\n","status":"withdrawn","published":"2026-02-27T08:49:48Z","modified":"2026-10-23T13:00:07.838019211Z","updated_at":"2026-11-02T15:54:01.953589Z"},{"id":"SUSE-SU-2026:20610-1","title":"Security update for kubevirt","description":"This update for kubevirt fixes the following issues:\n\nUpdate to version 1.7.0 (bsc#1257128).\n\nSecurity issues fixed:\n\n  - CVE-2025-64435: logic flaw in the virt-controller can lead to incorrect status updates and potentially causing a DoS\n    (bsc#1253189).\n  - CVE-2024-45310: kubevirt vendored github.com/opencontainers/runc/libcontainer/utils: runc can be tricked into\n    creating empty files/directories on host (bsc#1257422).\n  - CVE-2025-22872: incorrectly interpreted tags can cause content to be placed wrong scope during DOM construction\n    (bsc#1241772).\n  - CVE-2025-64432: fail to correctly validate certain fields in the client TLS certificate may allow an attacker to\n    bypass existing RBAC controls (bsc#1253181).\n  - CVE-2025-64433: improper symlink handling can allow to read arbitrary files (bsc#1253185).\n  - CVE-2025-64434: compromising virt-handler instance can lead to impersonate virt-api and execute privileged operations\n    (bsc#1253186).\n  - CVE-2025-64437: mishandling of symlinks can lead to compromising the CIA (bsc#1253194).\n  - CVE-2025-64324: a logic bug that allows an attacker to read and write arbitrary files owned by more privileged users\n    (bsc#1253748).\n\nOther updates and bugfixes:\n\n  - Upstream now uses stateless firmware for CoCo VMs.\n","status":"withdrawn","published":"2026-02-27T08:49:48Z","modified":"2026-10-21T01:00:09.098027193Z","updated_at":"2026-11-02T15:54:01.953589Z"}]}}