https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 01:25:03 +0000 https://cve.radiocsirt.org/vuln/bdu:2024-06891 bdu:2024-06891 https://cve.radiocsirt.org/vuln/bdu:2024-06891 https://cve.radiocsirt.org/vuln/bell-cve-2024-45310 <p><strong>Affected:</strong> Alpaquita:23: runc, Alpaquita:stream: runc</p> <p><strong>Affected:</strong> Alpaquita:23: runc, Alpaquita:stream: runc</p> https://cve.radiocsirt.org/vuln/bell-cve-2024-45310 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0641 certfr-2026-avi-0641 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0641 https://cve.radiocsirt.org/vuln/cleanstart-2026-cx82241 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: runc</p> <p>Package runc version 1.1.14-r0 fixes 40 vulnerabilities: ghsa-vvgc-356p-c3xw, CVE-2026-25679, CVE-2025-22873, CVE-2025-22872, CVE-2025-22871...</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: runc</p> <p>Package runc version 1.1.14-r0 fixes 40 vulnerabilities: ghsa-vvgc-356p-c3xw, CVE-2026-25679, CVE-2025-22873, CVE-2025-22872, CVE-2025-22871...</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-cx82241 https://cve.radiocsirt.org/vuln/euvd-2026-218589 EUVD-2026-218589 https://cve.radiocsirt.org/vuln/euvd-2026-218589 https://cve.radiocsirt.org/vuln/fkie_cve-2024-45310 <p>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&#39;s scope but the exact scope of protection hasn&#39;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.</p> <p>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&#39;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 SEL…</p> <p>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&#39;s scope but the exact scope of protection hasn&#39;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.</p> <p>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&#39;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 SEL…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-45310 https://cve.radiocsirt.org/vuln/ghsa-jfvp-7x6p-h2pv <p><strong>Affected:</strong> Go: github.com/opencontainers/runc</p> <p>### Impact runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with os.MkdirAll. While this can be used to create empty files, existing files **will not** be truncated.</p> <p>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&#39;s scope but the exact scope of protection hasn&#39;t been analysed.</p> <p>This is exploitable using runc directly as well as through Docker and Kubernetes.</p> <p>The CVSS score for this vulnerability is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).</p> <p>### Workarounds Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don&#39;t use /etc/sub[ug]id), this in practice means that an attacker would only be able to create inodes in world-writable directories.</p> <p>A strict enough SELinux or AppArmor policy could in principl…</p> <p><strong>Affected:</strong> Go: github.com/opencontainers/runc</p> <p>### Impact runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with os.MkdirAll. While this can be used to create empty files, existing files **will not** be truncated.</p> <p>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&#39;s scope but the exact scope of protection hasn&#39;t been analysed.</p> <p>This is exploitable using runc directly as well as through Docker and Kubernetes.</p> <p>The CVSS score for this vulnerability is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3.6).</p> <p>### Workarounds Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don&#39;t use /etc/sub[ug]id), this in practice means that an attacker would only be able to create inodes in world-writable directories.</p> <p>A strict enough SELinux or AppArmor policy could in principl…</p> https://cve.radiocsirt.org/vuln/ghsa-jfvp-7x6p-h2pv https://cve.radiocsirt.org/vuln/msrc_cve-2024-45310 msrc_CVE-2024-45310 https://cve.radiocsirt.org/vuln/msrc_cve-2024-45310 https://cve.radiocsirt.org/vuln/oesa-2024-2134 <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: runc</p> <p>runc is a CLI tool for spawning and running containers according to the OCI specification. Security Fix(es): 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&amp;apos;s scope but the exact scope of protection hasn&amp;apos;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&amp;apos;t use `/etc/sub[ug]…</p> <p><strong>Affected:</strong> openEuler:22.03-LTS-SP3: runc</p> <p>runc is a CLI tool for spawning and running containers according to the OCI specification. Security Fix(es): 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&amp;apos;s scope but the exact scope of protection hasn&amp;apos;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&amp;apos;t use `/etc/sub[ug]…</p> https://cve.radiocsirt.org/vuln/oesa-2024-2134 https://cve.radiocsirt.org/vuln/opensuse-su-2025:15424-1 <p>govulncheck-vulndb-0.0.20250807T150727-1.1 on GA media</p> <p>govulncheck-vulndb-0.0.20250807T150727-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:15424-1 https://cve.radiocsirt.org/vuln/rhsa-2026:3406 <p>nodejs-underscore: Arbitrary code execution via the template function runc: runc can be tricked into creating empty files/directories on host golang-jwt: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt nanoid: nanoid mishandles non-integer values Scrapy: python-scrapy: brotli: Python brotli decompression bomb DoS form-data: Unsafe random function in form-data util-linux: util-linux: Heap buffer overread in setpwnam() when processing 256-byte usernames golang.org/x/oauth2/jws: Unexpected memory consumption during token parsing in golang.org/x/oauth2/jws dompurify: Mutation XSS in DOMPurify Due to Improper Template Literal Handling urllib3: urllib3 redirects are not disabled when retries are disabled on PoolManager instantiation urllib3: urllib3 does not control redirects in browsers and Node.js urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion urllib3: urllib3 Streaming API improperly handles highly compressed data urllib3: urllib3 vulnerable to decompression-bomb safeguard bypass when following HTTP redirects (streaming API)</p> <p>nodejs-underscore: Arbitrary code execution via the template function runc: runc can be tricked into creating empty files/directories on host golang-jwt: Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations in golang-jwt nanoid: nanoid mishandles non-integer values Scrapy: python-scrapy: brotli: Python brotli decompression bomb DoS form-data: Unsafe random function in form-data util-linux: util-linux: Heap buffer overread in setpwnam() when processing 256-byte usernames golang.org/x/oauth2/jws: Unexpected memory consumption during token parsing in golang.org/x/oauth2/jws dompurify: Mutation XSS in DOMPurify Due to Improper Template Literal Handling urllib3: urllib3 redirects are not disabled when retries are disabled on PoolManager instantiation urllib3: urllib3 does not control redirects in browsers and Node.js urllib3: urllib3: Unbounded decompression chain leads to resource exhaustion urllib3: urllib3 Streaming API improperly handles highly compressed data urllib3: urllib3 vulnerable to decompression-bomb safeguard bypass when following HTTP redirects (streaming API)</p> https://cve.radiocsirt.org/vuln/rhsa-2026:3406 https://cve.radiocsirt.org/vuln/suse-su-2024:3324-1 <p>Security update for runc</p> <p>Security update for runc</p> https://cve.radiocsirt.org/vuln/suse-su-2024:3324-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-45310 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: runc, Ubuntu:Pro:18.04:LTS: runc, Ubuntu:20.04:LTS: runc, Ubuntu:20.04:LTS: runc-app, Ubuntu:22.04:LTS: runc, Ubuntu:22.04:LTS: runc-app, Ubuntu:24.04:LTS: runc, Ubuntu:24.04:LTS: runc-app</p> <p>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&#39;s scope but the exact scope of protection hasn&#39;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&#39;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 SELi…</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: runc, Ubuntu:Pro:18.04:LTS: runc, Ubuntu:20.04:LTS: runc, Ubuntu:20.04:LTS: runc-app, Ubuntu:22.04:LTS: runc, Ubuntu:22.04:LTS: runc-app, Ubuntu:24.04:LTS: runc, Ubuntu:24.04:LTS: runc-app</p> <p>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&#39;s scope but the exact scope of protection hasn&#39;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&#39;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 SELi…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2024-45310 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0632 <p>Ein Angreifer kann mehrere Schwachstellen in IBM MQ ausnutzen, um Dateien zu manipulieren und Sicherheitsmaßnahmen zu umgehen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in IBM MQ ausnutzen, um Dateien zu manipulieren und Sicherheitsmaßnahmen zu umgehen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0632