VYPR

CWE-379

Creation of Temporary File in Directory with Insecure Permissions

BaseIncompleteLikelihood: Low

Description

The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.

On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached.

Hierarchy (View 1000)

Parents

Children

none

CVEs mapped to this weakness (10)

CVESevRiskCVSSEPSSKEVPublishedDescription
CVE-2025-27148Hig0.578.80.00Feb 25, 2025Gradle 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-32438Hig0.508.80.00Apr 15, 2025make-initrd-ng is a tool for copying binaries and their dependencies. Local privilege escalation affecting all NixOS users. With systemd.shutdownRamfs.enable enabled (the default) a local user is able to create a program that will be executed by root during shutdown. Patches exist for NixOS 24.11 and 25.05 / unstable. As a workaround, set systemd.shutdownRamfs.enable = false;.
CVE-2024-7562Hig0.470.00Jun 12, 2025A potential elevated privilege issue has been reported with InstallShield built Standalone MSI setups having multiple InstallScript custom actions configured. All supported versions (InstallShield 2023 R2, InstallShield 2022 R2 and InstallShield 2021 R2) are affected by this issue.
CVE-2019-25677Med0.406.20.00Apr 5, 2026WinRAR 5.61 contains a denial of service vulnerability that allows local attackers to crash the application by placing a malformed winrar.lng language file in the installation directory. Attackers can trigger the crash by opening an archive and pressing the test button, causing an access violation at memory address 004F1DB8 when the application attempts to read invalid data.
CVE-2025-32802Med0.406.10.00May 28, 2025Kea configuration and API directives can be used to overwrite arbitrary files, subject to permissions granted to Kea. Many common configurations run Kea as root, leave the API entry points unsecured by default, and/or place the control sockets in insecure paths. This issue affects Kea versions 2.4.0 through 2.4.1, 2.6.0 through 2.6.2, and 2.7.0 through 2.7.8.
CVE-2013-1815Med0.406.10.00Apr 10, 2013A flaw was found in PackStack. This vulnerability allows a local user to modify deployed systems by changing the answer file, which is created in insecure directories such as /tmp or the current working directory. This insecure file creation could lead to unauthorized system modifications.
CVE-2025-10279Hig0.397.00.00Feb 2, 2026In mlflow version 2.20.3, the temporary directory used for creating Python virtual environments is assigned insecure world-writable permissions (0o777). This vulnerability allows an attacker with write access to the `/tmp` directory to exploit a race condition and overwrite `.py` files in the virtual environment, leading to arbitrary code execution. The issue is resolved in version 3.4.0.
CVE-2025-71176Med0.376.80.00Jan 22, 2026pytest through 9.0.2 on UNIX relies on directories with the /tmp/pytest-of-{user} name pattern, which allows local users to cause a denial of service or possibly gain privileges.
CVE-2026-42191Med0.356.50.00May 12, 2026OpenTelemetry.Exporter.OpenTelemetryProtocol is the OTLP (OpenTelemetry Protocol) exporter implementation. From 1.8.0 to 1.15.2, the OTLP disk retry feature in OpenTelemetry.Exporter.OpenTelemetryProtocol silently fell back to Path.GetTempPath() when OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY=disk was set but OTEL_DOTNET_EXPERIMENTAL_OTLP_DISK_RETRY_DIRECTORY_PATH was not configured. The exporter stored and loaded *.blob files under fixed, signal-named subdirectories (traces, metrics, logs) beneath that shared temporary root path. On multi-user systems where the temporary directory is accessible to other local accounts, this allows an attacker to write crafted *.blob files, read *.blob files written by the application between export failures, or deposit numerous or oversized blob files, degrading retry-loop performance or consuming disk space. This vulnerability is fixed in 1.15.3.
CVE-2026-2817Med0.294.40.00Feb 19, 2026Use of insecure directory in Spring Data Geode snapshot import extracts archives into predictable, permissive directories under the system temp location. On shared hosts, a local user with basic privileges can access another user’s extracted snapshot contents, leading to unintended exposure of cache data.