CVE-2025-27148: Gradle Privilege Escalation Vulnerability

CVE-2025-27148 Overview

CVE-2025-27148 is a local privilege escalation vulnerability affecting Gradle's native-platform tool, which provides Java bindings for native APIs. On Unix-like systems, the library initialization process creates files in the system temporary directory with open permissions, allowing any user to create and delete files. An attacker with local access can exploit a race condition by rapidly deleting and recreating files in the temporary directory during Gradle build initialization, potentially achieving privilege escalation.

Critical Impact

Local attackers can escalate privileges on vulnerable Unix-like systems by exploiting race conditions in Gradle's native library initialization, potentially compromising build infrastructure and development environments.

Affected Products

• Gradle 8.12 (exact version only)
• net.rubygrapefruit:native-platform versions prior to 0.22-milestone-28
• Unix-like operating systems without sticky bit set on /tmp

Discovery Timeline

• 2025-02-25 - CVE CVE-2025-27148 published to NVD
• 2025-02-25 - Last updated in NVD database

Technical Details for CVE-2025-27148

Vulnerability Analysis

This vulnerability stems from insecure temporary file handling in Gradle's native-platform library (CWE-378: Creation of Temporary File With Insecure Permissions). When the Native.get(Class<>) method is called without first calling Native.init(File) with a non-null working file path argument, the library initializes itself using the system temporary directory. The vulnerable code path exists in NativeLibraryLocator.java at lines 68 through 78.

The attack requires local access to the system and leverages a Time-of-Check Time-of-Use (TOCTOU) race condition. An attacker monitoring the temporary directory can quickly delete legitimate library files and replace them with malicious versions before Gradle loads them. Because the temporary directory typically has world-writable permissions (unless the sticky bit is set), any local user can manipulate these files.

Windows users and users of modern macOS versions are not vulnerable due to different temporary directory permission models. Additionally, Unix-like systems with the sticky bit set on /tmp or with /tmp mounted as noexec are protected against this attack vector.

Root Cause

The root cause lies in the native-platform library's fallback behavior when proper initialization is not performed. In versions prior to 0.22-milestone-28, if Native.init(File) was not called with a safe, user-controlled path before Native.get(Class<>), the library would default to using the system temporary directory for storing native binaries. This directory is typically world-writable on Unix-like systems, creating an opportunity for local privilege escalation through file manipulation.

Attack Vector

The attack exploits the local access vector by targeting the temporary directory during Gradle build execution. An attacker must:

1. Monitor the system temporary directory for Gradle native library files being created
2. Quickly delete the legitimate native library file after creation
3. Replace it with a malicious library containing attacker-controlled code
4. Wait for Gradle to load the malicious library with the build user's privileges

The attack window is the brief period between file creation and library loading. Success depends on winning the race condition, which may require multiple attempts. The vulnerability allows code execution with the privileges of the user running the Gradle build, which in CI/CD environments could be highly privileged service accounts.

Detection Methods for CVE-2025-27148

Indicators of Compromise

• Unexpected file creation or deletion patterns in /tmp during Gradle build processes
• Modified or replaced native library files in the system temporary directory
• Anomalous process execution spawned from Gradle build processes
• Suspicious file access patterns from non-build user accounts targeting Gradle temporary files

Detection Strategies

• Monitor file system activity in /tmp and java.io.tmpdir locations for rapid create/delete cycles during Gradle executions
• Audit Gradle version usage across development and CI/CD systems to identify instances of version 8.12
• Implement file integrity monitoring on temporary directories used by build processes
• Review dependency trees for usage of net.rubygrapefruit:native-platform versions prior to 0.22-milestone-28

Monitoring Recommendations

• Enable detailed logging for file operations in temporary directories during build processes
• Configure security tools to alert on privilege escalation attempts from build tool processes
• Monitor for unusual user account activity accessing build system temporary files
• Implement baseline monitoring for Gradle process behavior to detect anomalous library loading

How to Mitigate CVE-2025-27148

Immediate Actions Required

• Upgrade Gradle to version 8.12.1 or 8.13 immediately
• Upgrade net.rubygrapefruit:native-platform to version 0.22-milestone-28 or later
• Verify that the sticky bit is set on /tmp on all Unix-like build systems
• Audit CI/CD pipelines and development machines for vulnerable Gradle versions

Patch Information

The vulnerability has been addressed in multiple releases. Gradle 8.12.1 specifically fixes this issue, while Gradle 8.13 upgrades to a patched version of the native-platform library that no longer contains the vulnerability. The underlying library fix is available in net.rubygrapefruit:native-platform version 0.22-milestone-28, which makes initialization mandatory and no longer uses the system temporary directory by default.

For detailed information about the fixes, see GitHub Pull Request #32025 for the Gradle fix and GitHub Pull Request #353 for the native-platform library fix. Security advisories are available at GitHub Security Advisory GHSA-89qm and GitHub Security Advisory GHSA-2xxp.

Workarounds

• Set the sticky bit on the system temporary directory to restrict file deletion to file owners only
• Mount /tmp with the noexec option to prevent execution of files from the temporary directory (note: this prevents Gradle 8.12 from starting)
• Redirect the Java temporary directory by setting the java.io.tmpdir system property to a secure location with restricted permissions
• Ensure proper initialization of the native-platform library using Native.init(File) with a safe, user-controlled path before any Native.get(Class<>) calls

# Set sticky bit on temporary directory
chmod +t /tmp

# Or redirect Java temp directory to secure location
mkdir -p /secure/gradle-tmp
chmod 700 /secure/gradle-tmp
export JAVA_OPTS="-Djava.io.tmpdir=/secure/gradle-tmp"