| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| qemu-dm.debug in Xen 3.2.1 allows local users to overwrite arbitrary files via a symlink attack on the /tmp/args temporary file. |
| fence_manual, as used in fence 2.02.00-r1 and possibly cman, allows local users to modify arbitrary files via a symlink attack on the fence_manual.fifo temporary file. |
| The (1) fence_apc and (2) fence_apc_snmp programs, as used in (a) fence 2.02.00-r1 and possibly (b) cman, when running in verbose mode, allows local users to append to arbitrary files via a symlink attack on the apclog temporary file. |
| (1) xenbaked and (2) xenmon.py in Xen 3.1 and earlier allow local users to truncate arbitrary files via a symlink attack on /tmp/xenq-shm. |
| freeradius-dialupadmin in freeradius 2.0.4 allows local users to overwrite arbitrary files via a symlink attack on temporary files in (1) backup_radacct, (2) clean_radacct, (3) monthly_tot_stats, (4) tot_stats, and (5) truncate_radacct. |
| Asterisk is an open source private branch exchange and telephony toolkit. Prior to versions 20.7-cert9, 20.18.2, 21.12.1, 22.8.2, and 23.2.2, when ast_coredumper writes its gdb init and output files to a directory that is world-writable (for example /tmp), an attacker with write permission(which is all users on a linux system) to that directory can cause root to execute arbitrary commands or overwrite arbitrary files by controlling the gdb init file and output paths. This issue has been patched in versions 20.7-cert9, 20.18.2, 21.12.1, 22.8.2, and 23.2.2. |
| In Splunk Enterprise versions below 10.2.1, 10.0.5, 9.4.10, and 9.3.11, and Splunk Cloud Platform versions below 10.4.2603.0, 10.3.2512.5, 10.2.2510.9, 10.1.2507.19, 10.0.2503.13, and 9.3.2411.127, a low-privileged user that does not hold the `admin` or `power` Splunk roles could potentially perform a Remote Code Execution (RCE) by uploading a malicious file to the `$SPLUNK_HOME/var/run/splunk/apptemp` directory due to improper handling and insufficient isolation of temporary files within the `apptemp` directory. |
| Use 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. |
| An Insecure Temporary File vulnerability in openSUSE sdbootutil allows local users to pre-create a directory to achieve various effects like:
* gain access to possible private information found in /var/lib/pcrlock.d
* manipulate the data backed up in /tmp/pcrlock.d.bak, therefore violating the integrity of the data should it be restored.
* overwrite protected system files with data from /var/lib/pcrlock.d by placing symlinks to existing files in the directory tree in /tmp/pcrlock.d.bak.
This issue affects sdbootutil: from ? before 5880246d3a02642dc68f5c8cb474bf63cdb56bca. |
| znew in the gzip package allows local users to overwrite arbitrary files via a symlink attack on temporary files. |
| Race condition in shtool 2.0.1 and earlier allows local users to create or modify arbitrary files via a symlink attack on the .shtool.$$ temporary file, a different vulnerability than CVE-2005-1759. |
| An issue was addressed with improved handling of temporary files. This issue is fixed in macOS Tahoe 26.3. An app may be able to access user-sensitive data. |
| A logging issue was addressed with improved data redaction. This issue is fixed in iOS 26.3 and iPadOS 26.3, macOS Tahoe 26.3, tvOS 26.3, watchOS 26.3. A user may be able to view sensitive user information. |
| JumpCloud Remote Assist for Windows versions prior to 0.317.0 include an uninstaller that is invoked by the JumpCloud Windows Agent as NT AUTHORITY\SYSTEM during agent uninstall or update operations. The Remote Assist uninstaller performs privileged create, write, execute, and delete actions on predictable files inside a user-writable %TEMP% subdirectory without validating that the directory is trusted or resetting its ACLs when it already exists. A local, low-privileged attacker can pre-create the directory with weak permissions and leverage mount-point or symbolic-link redirection to (a) coerce arbitrary file writes to protected locations, leading to denial of service (e.g., by overwriting sensitive system files), or (b) win a race to redirect DeleteFileW() to attacker-chosen targets, enabling arbitrary file or folder deletion and local privilege escalation to SYSTEM. This issue is fixed in JumpCloud Remote Assist 0.317.0 and affects Windows systems where Remote Assist is installed and managed through the Agent lifecycle. |
| bash-git-prompt 2.6.1 through 2.7.1 insecurely uses the /tmp/git-index-private$$ file, which has a predictable name. |
| 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. |
| Insecure creation of temporary files allows local users on systems with non-default configurations to cause denial of service or set the encryption key for a filesystem |
| A post-authentication absolute path traversal vulnerability in SonicOS management allows a remote attacker to read an arbitrary file. |
| readline.sh in socat before1.8.0.2 relies on the /tmp/$USER/stderr2 file. |
| Kea 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. |
