CVE-2025-27148
Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HSummary
CVE-2025-27148 is a high-severity Creation of Temporary File With Insecure Permissions (CWE-378) vulnerability in Wikipedia (inferred from references). Its CVSS base score is 8.8 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data from Local System (T1005); ranked at the 15th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-6 (Least Privilege) and SC-4 (Information in Shared System Resources) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-27148 is a local privilege escalation vulnerability in the net.rubygrapefruit:native-platform library, versions prior to 0.22-milestone-28, which provides Java bindings for native APIs in Gradle, a build automation tool. The issue arises on Unix-like systems where the system temporary directory has open permissions allowing multiple users to create and delete files. If the Native.get(Class<>) method is called without prior Native.init(File) initialization and with a non-null working file path, the library initializes using the system temporary directory, making it susceptible to a time-of-check to time-of-use race condition where an attacker can delete and recreate files during this process. This specifically affects Gradle 8.12, which had code paths relying on copying binaries to the system temporary directory without proper safeguards.
A local attacker with low privileges (PR:L) on vulnerable Unix-like systems can exploit this by racing to manipulate files in the system temporary directory during library initialization, triggered by any Gradle execution. Successful exploitation leads to high confidentiality, integrity, and availability impacts (C:H/I:H/A:H) with changed scope (S:C), as scored at CVSS 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). Windows and modern macOS users are unaffected, as are Unix-like systems with the sticky bit set on the temporary directory or mounted with noexec.
Gradle security advisories (GHSA-465q-w4mf-4f4r, GHSA-89qm-pxvm-p336) and the fixing pull request (gradle/gradle#32025) recommend updating to net.rubygrapefruit:native-platform 0.22-milestone-28 or later, Gradle 8.12.1, or Gradle 8.13, which mandate proper initialization avoiding the system temporary directory unless explicitly provided. Workarounds for affected versions include calling Native.init(File) with a safe path, setting the sticky bit on the system temporary directory to restrict deletions, mounting it noexec (which prevents Gradle 8.12 startup), or setting the java.io.tmpdir system property to a user-only accessible directory.
This vulnerability is tied to CWEs-378 and CWE-379 (insecure temp file creation/deletion) and highlights risks in multi-user environments without standard Unix protections like sticky bits on /tmp. No real-world exploitation is documented in the provided details.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-5367
Vulnerability Data
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.…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 1 hardening rule · 1 OS baseline
V15.4.2
Mitigating Controls (NIST 800-53 r5) AI
AC-6 limits privileges granted to processes creating or accessing temporary files, reducing blast radius of insecure permissions.
SC-4 directly stops unauthorized information transfer through shared resources such as temporary files created with weak permissions.
AC-3 enforces access authorizations on system resources including files, structurally stopping insecure temporary file permissions from being exploitable.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require proper temporary-file creation and permission handling.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure coding standards directly prohibit insecure temporary file creation and permissions.
Security testing can detect insecure temporary files but does not prevent their creation.
Secure SDLC mandates secure handling of temporary files and permissions.
Application security requirements include secure creation and permissioning of temporary files.
Secure architecture principles require least-privilege file creation and access controls.
Information access restriction can limit exposure but does not address file creation itself.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 8 (1 rule)
- V-248577 OL 8 must enable kernel parameters to enforce Discretionary Access Control (DAC) on symlinks. prevents CWE-379