CVE-2025-27148 SUSE CVE security@suse.de SUSE Security Team SUSE CVE-2025-27148 Interim 1 1 2025-03-01T00:11:43Z current 2025-03-01T00:11:43Z 2025-03-01T00:11:43Z cve-database/bin/generate-cvrf-cve.pl 2020-12-27T01:00:00Z CVE-2025-27148 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<>)` 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, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the "sticky" bit set or `noexec` on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. Mounting `/tmp` as `noexec` will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. The CVRF data is provided by SUSE under the Creative Commons License 4.0 with Attribution (CC-BY-4.0). https://www.suse.com/support/security/rating/ SUSE Security Ratings SLES-LTSS-TERADATA 15 SP2 SUSE Linux Enterprise Module for Development Tools 15 SP6 SUSE Linux Enterprise High Performance Computing 15 SP3-LTSS SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS SUSE Linux Enterprise Module for Development Tools 15 SP6 SUSE Linux Enterprise Server 15 SP2-LTSS SUSE Linux Enterprise Server 15 SP3-LTSS SUSE Linux Enterprise Server 15 SP4-LTSS SUSE Linux Enterprise Server 15 SP5-LTSS SUSE Linux Enterprise Module for Development Tools 15 SP6 SUSE Linux Enterprise Server Teradata 15 SP4 SUSE Linux Enterprise Server for SAP Applications 15 SP3 SUSE Linux Enterprise Server for SAP Applications 15 SP4 SUSE Linux Enterprise Server for SAP Applications 15 SP5 SUSE Linux Enterprise Module for Development Tools 15 SP6 openSUSE Leap 15.6 gradle gradle as a component of SLES-LTSS-TERADATA 15 SP2 gradle as a component of SUSE Linux Enterprise High Performance Computing 15 SP3-LTSS gradle as a component of SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS gradle as a component of SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS gradle as a component of SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS gradle as a component of SUSE Linux Enterprise Module for Development Tools 15 SP6 gradle as a component of SUSE Linux Enterprise Server 15 SP2-LTSS gradle as a component of SUSE Linux Enterprise Server 15 SP3-LTSS gradle as a component of SUSE Linux Enterprise Server 15 SP4-LTSS gradle as a component of SUSE Linux Enterprise Server 15 SP5-LTSS gradle as a component of SUSE Linux Enterprise Server Teradata 15 SP4 gradle as a component of SUSE Linux Enterprise Server for SAP Applications 15 SP3 gradle as a component of SUSE Linux Enterprise Server for SAP Applications 15 SP4 gradle as a component of SUSE Linux Enterprise Server for SAP Applications 15 SP5 gradle as a component of openSUSE Leap 15.6 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<>)` 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, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the "sticky" bit set or `noexec` on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. Mounting `/tmp` as `noexec` will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only. CVE-2025-27148 SLES-LTSS-TERADATA 15 SP2:gradle SUSE Linux Enterprise High Performance Computing 15 SP3-LTSS:gradle SUSE Linux Enterprise High Performance Computing 15 SP4-LTSS:gradle SUSE Linux Enterprise High Performance Computing 15 SP5-ESPOS:gradle SUSE Linux Enterprise High Performance Computing 15 SP5-LTSS:gradle SUSE Linux Enterprise Module for Development Tools 15 SP6:gradle SUSE Linux Enterprise Server 15 SP2-LTSS:gradle SUSE Linux Enterprise Server 15 SP3-LTSS:gradle SUSE Linux Enterprise Server 15 SP4-LTSS:gradle SUSE Linux Enterprise Server 15 SP5-LTSS:gradle SUSE Linux Enterprise Server Teradata 15 SP4:gradle SUSE Linux Enterprise Server for SAP Applications 15 SP3:gradle SUSE Linux Enterprise Server for SAP Applications 15 SP4:gradle SUSE Linux Enterprise Server for SAP Applications 15 SP5:gradle openSUSE Leap 15.6:gradle important