CVE Database

Insecure Temporary File vulnerability in Hitachi Disk Array Driver for AIX and Hitachi Disk Array Driver for Virtual I/O Server. This issue affects Hitachi Disk Array Driver for AIX: from 01-00 before 01-23-/A; Hitachi Disk Array Driver for Virtual I/O Server: from 01-04 before 01-23-/A.

Fortra BoKS Manager contains an insecure temporary file vulnerability in bccgethostcert. The utility creates predictable temporary files without first setting a restrictive umask. A local user on the BoKS Master who can read files under BOKS_tmp may be able to obtain CA secret or host private-key material while the utility runs, or obtain CA secret material left behind after successful certificate creation.

A local attacker on a multi-user host can pre-create the deterministic cache path and plant a malicious ONNX model file. Spring AI 2.0.0 Spring AI 1.1.0 - 1.1.8 Spring AI 1.0.0 - 1.0.9

Faktory is a language-agnostic background job server. In versions prior to 1.10.0, the embedded Redis bootstrapper is vulnerable to an insecure temporary file flaw that lets a local unprivileged user hijack the Redis configuration and escalate to root. It writes its startup configuration to a fixed, predictable, world-writable path, /tmp/redis.conf, only creating the file if it does not already exist and never validating it on later boots. Because /tmp is world-writable, a local unprivileged user can pre-create /tmp/redis.conf with attacker-chosen Redis directives before Faktory starts, and Faktory will use the planted file verbatim. Faktory only overrides the unixsocket, dir, and logfile options, leaving directives such as bind, protected-mode, requirepass, and loadmodule attacker-controlled. This lets an attacker silently expose the entire job queue over an unauthenticated network port with no visible error to the administrator. Because the official systemd unit runs Faktory, and the redis-server child it spawns, as root, an attacker can also supply a loadmodule directive to execute arbitrary native code in the root-owned Redis process, escalating from a local unprivileged user to root. This issue is fixed in version 1.10.0.

A vulnerability in the web-based management interface of an ECOS device could allow a highly privileged, authenticated remote attacker to access the device's filesystem. Successful exploitation of this vulnerability could allow an attacker to access sensitive files and tamper with or delete system data.

CodexBar prior to 0.32.0 contains a privilege escalation vulnerability in the CLI installer that allows local attackers to execute arbitrary commands as root by exploiting a race condition in temporary file handling. The installer creates a temporary file with mktemp, writes a privileged shell payload into it, and executes it with administrator privileges via bash, allowing a same-user local process to rewrite the installer body before the administrator prompt is approved, causing attacker-controlled commands to run as root.

The Aranda File Server (AFS) component in Aranda Software Aranda Service Desk before 8.3.12 stores daily activity logs with predictable names in a publicly accessible directory, which allows unauthenticated remote attackers to obtain direct virtual paths of uploaded files and bypass access controls to download sensitive documents containing PII.

A local attacker on the same host as the application may be able to take control of the directory used by `ApplicationTemp`. When `server.servlet.session.persistent` is set to `true` and the attack persists across application restarts, this may allow the attacker to read session information and hijack authenticated users or deploy a gadget chain and execute code as the application's user. Affected: Spring Boot 4.0.0–4.0.5 (fix 4.0.6), 3.5.0–3.5.13 (fix 3.5.14), 3.4.0–3.4.15 (fix 3.4.16), 3.3.0–3.3.18 (fix 3.3.19), 2.7.0–2.7.32 (fix 2.7.33); predictable temp directory / `ApplicationTemp` ownership verification. Versions that are no longer supported are also affected per vendor advisory.

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.

A vulnerability was detected in Enter Software Iperius Backup up to 8.7.3. Affected is an unknown function of the file C:\ProgramData\IperiusBackup\Jobs\ of the component Backup Service. Performing a manipulation results in creation of temporary file with insecure permissions. The attack is only possible with local access. A high degree of complexity is needed for the attack. The exploitability is told to be difficult. The exploit is now public and may be used. Upgrading to version 8.7.4 is able to address this issue. It is recommended to upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

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.