Gradle 8.12.0 Setting temp file

Summaryinfo

A vulnerability classified as problematic has been found in Gradle 8.12.0. The affected element is an unknown function of the component Setting Handler. Performing a manipulation results in temp file. This vulnerability is identified as CVE-2025-27148. The attack is only possible with local access. There is not any exploit available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as problematic, was found in Gradle 8.12.0. This affects some unknown processing of the component Setting Handler. The manipulation with an unknown input leads to a temp file vulnerability. CWE is classifying the issue as CWE-378. Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack. This is going to have an impact on confidentiality, integrity, and availability. The summary by CVE is:

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 advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2025-27148 since 02/19/2025. The exploitability is told to be easy. An attack has to be approached locally. Neither technical details nor an exploit are publicly available.

Upgrading to version 8.12.1 or 8.13.0 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Name

• Gradle

Version

• 8.12.0

Website

• Product: https://github.com/gradle/gradle/

CPE 2.3info

• 🔍

CPE 2.2info

• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion