https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 16:00:40 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2025-27148 <p><strong>Affected:</strong> Alpaquita:stream: gradle</p> <p><strong>Affected:</strong> Alpaquita:stream: gradle</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-27148 https://cve.radiocsirt.org/vuln/bit-gradle-2025-27148 <p><strong>Affected:</strong> Bitnami: gradle</p> <p>Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.</p> <p>In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class&lt;&gt;)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.</p> <p>Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, rely…</p> <p><strong>Affected:</strong> Bitnami: gradle</p> <p>Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.</p> <p>In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class&lt;&gt;)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.</p> <p>Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, rely…</p> https://cve.radiocsirt.org/vuln/bit-gradle-2025-27148 https://cve.radiocsirt.org/vuln/euvd-2026-219092 EUVD-2026-219092 https://cve.radiocsirt.org/vuln/euvd-2026-219092 https://cve.radiocsirt.org/vuln/fkie_cve-2025-27148 <p>Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.</p> <p>In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class&lt;&gt;)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.</p> <p>Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, rely…</p> <p>Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.</p> <p>In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class&lt;&gt;)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.</p> <p>Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, rely…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-27148 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-27148 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: gradle, Ubuntu:Pro:18.04:LTS: gradle, Ubuntu:20.04:LTS: gradle, Ubuntu:22.04:LTS: gradle, Ubuntu:24.04:LTS: gradle, Ubuntu:25.10: gradle, Ubuntu:26.04:LTS: gradle</p> <p>Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class&lt;&gt;)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe. Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relyin…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: gradle, Ubuntu:Pro:18.04:LTS: gradle, Ubuntu:20.04:LTS: gradle, Ubuntu:22.04:LTS: gradle, Ubuntu:24.04:LTS: gradle, Ubuntu:25.10: gradle, Ubuntu:26.04:LTS: gradle</p> <p>Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. In net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class&lt;&gt;)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe. Gradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relyin…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-27148