| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Creation of Temporary File With Insecure Permissions vulnerability in Apache XML Graphics FOP.
This issue affects Apache XML Graphics FOP: through 2.11.
Users are recommended to upgrade to version 2.12, which fixes the issue. |
| Creation of temporary file in directory with insecure permissions in .NET Aspire allows an authorized attacker to elevate privileges locally. |
| Incomplete internal state distinction in the MigTD's SPDM responder for the Intel(R) TDX Migration Trust Domain (MigTD) within Ring 0: Hypervisor may allow an escalation of privilege. System software adversary with a privileged user combined with a low complexity attack may enable data corruption. This result may potentially occur via adjacent access when attack requirements are not present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (none), integrity (high) and availability (none) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts. |
| When a non-default stateful session bean passivation strategy is configured, passivated bean state is written to predictably named files in the shared system temporary directory, reusing files that already exist there, and is deserialized on activation. A local attacker who can write to that directory can read passivated session state or supply data that the server deserializes, potentially leading to code execution as the server process. Users are recommended to upgrade to version 10.3.0 or 11.0.0-M2, which fix the issue. |
| Powerlevel10k before 1.20.19 contains an insecure temporary directory vulnerability in the bundled gitstatus/install script that reuses attacker-creatable directories when mktemp fails. Local attackers can pre-create the predictable gitstatus-install.tmp directory to replace the extracted gitstatusd binary, which then executes with the victim's privileges. |
| A time-of-check to time-of-use (TOCTOU) race condition in the Sandisk Dashboard installer allows a local, authenticated standard user to replace an installer-staged binary in a user-writable temporary directory between validation and execution. The elevated installer then executes the attacker-controlled binary, resulting in local privilege escalation to a high-integrity (administrative) context. This issue affects Sandisk Dashboard through 5.2.2.3. |
| A flaw has been found in fushengqian fuint up to 36cc31b08d77facc94e8959afa02224891b4fe5f. This issue affects the function receipt of the file ClientOrderController.java. Executing a manipulation can lead to state issue. The attack may be performed from remote. This product utilizes a rolling release system for continuous delivery, and as such, version information for affected or updated releases is not disclosed. The vendor was contacted early about this disclosure but did not respond in any way. |
| As part of Cisco's ongoing commitment to proactive security and product quality, the Cisco Expressway Series software engineering team has conducted a comprehensive internal security review. This review resulted in software hardening releases that address multiple internally discovered vulnerabilities.
The vulnerabilities tracked by CVE-2026-76497 are related to issues concerning insecure temporary files that are grouped under the Common Weakness Enumeration (CWE) Base CWE-377. |
| A vulnerability was found in insights-client. This security issue occurs because of insecure file operations or unsafe handling of temporary files and directories that lead to local privilege escalation. Before the insights-client has been registered on the system by root, an unprivileged local user or attacker could create the /var/tmp/insights-client directory (owning the directory with read, write, and execute permissions) on the system. After the insights-client is registered by root, an attacker could then control the directory content that insights are using by putting malicious scripts into it and executing arbitrary code as root (trivially bypassing SELinux protections because insights processes are allowed to disable SELinux system-wide). |
| Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu or Terraform to scale. Prior to 1.1.1, the terragrunt catalog command derives a predictable per-repository catalog clone root under the shared system temporary directory and follows a symlink already placed at that path. A local attacker who can write to the temporary directory and predict the cataloged repository can redirect cleanup and cloning outside the intended root, causing an existing repository-named directory to be deleted and replaced in the victim's security context. The attack requires the victim to run terragrunt catalog on a shared host while the symlink is present, and it is not remotely exploitable. This issue is fixed in version 1.1.1. |
| nnn through 5.3 contains an insecure temporary file vulnerability in the pdfread and nuke plugins that allows local attackers to overwrite files by exploiting predictable paths in /tmp. Attackers can pre-create a symlink at the name-derived or PID-derived path so the victim's plugin truncates and overwrites any file the victim can write. |
| In all versions of PyTorch's TorchServe, a predictable extraction directory in /tmp lets a local user swap the model handler and run code as the TorchServe service account leading to local privilege escalation. |
| Missing integrity verification in the Progress Software Fiddler Download and Setup Skill on Linux, macOS, and Windows which allows an attacker to compromise or influence a release component and execute attacker-controlled code when a user runs the skill. On macOS, the skill stages the package at a predictable path and installs it with administrator privileges, which may allow code execution with root privileges after user approval. A local process may also replace the staged macOS package while the skill waits for approval. |
| Flatpak creates temporary child repository directories under the user cache with world-writable permissions (0777). On multi-user systems with a permissive umask, other local users could read or modify the temporary directory used while installing apps or runtimes, potentially causing installation failures (denial of service); tampered content would fail signature/digest verification rather than being trusted. |
| Flatpak writes the OCI repository authentication token with world-readable permissions (0644) in the system-helper's cache directory, allowing other local users on a multi-user system to read the token and impersonate the authenticated user against the OCI repository. Only OCI-based sources (e.g. as used by Fedora) are affected; libostree-based sources such as Flathub are not. |
| CallBackery versions before 0.62.0 for Perl leave a world-readable dump of the configuration database in /tmp when taking a configuration backup.
getConfigBlob() has the sqlite3 shell write the dump to /tmp/cbdump<pid> and never removes it. The file takes the process umask, and a symlink planted at that predictable name is followed.
The dump holds every user's password hash and every value saved by the application's forms. A local user can read these after any backup, and may redirect the dump to a file of their choosing. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Add missing save/restore handling of LBR MSRs
MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by
KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So
save/restore is completely broken.
Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to
LBR MSRs from userspace only (as they are read-only MSRs) if LBR
virtualization is enabled. Additionally, to correctly restore L1's LBRs
while L2 is running, make sure the LBRs are copied from the captured
VMCB01 save area in svm_copy_vmrun_state().
Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't
reported as an MSR to save/restore.
Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already
handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM:
Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the
unsupported userspace write into a nop).
[sean: guard with lbrv checks, massage changelog] |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: don't cache extent during splitting extent
Caching extents during the splitting process is risky, as it may result
in stale extents remaining in the status tree. Moreover, in most cases,
the corresponding extent block entries are likely already cached before
the split happens, making caching here not particularly useful.
Assume we have an unwritten extent, and then DIO writes the first half.
[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent
[UUUUUUUUUUUUUUUU] extent status tree
|<- ->| ----> dio write this range
First, when ext4_split_extent_at() splits this extent, it truncates the
existing extent and then inserts a new one. During this process, this
extent status entry may be shrunk, and calls to ext4_find_extent() and
ext4_cache_extents() may occur, which could potentially insert the
truncated range as a hole into the extent status tree. After the split
is completed, this hole is not replaced with the correct status.
[UUUUUUU|UUUUUUUU] on-disk extent U: unwritten extent
[UUUUUUU|HHHHHHHH] extent status tree H: hole
Then, the outer calling functions will not correct this remaining hole
extent either. Finally, if we perform a delayed buffer write on this
latter part, it will re-insert the delayed extent and cause an error in
space accounting.
In adition, if the unwritten extent cache is not shrunk during the
splitting, ext4_cache_extents() also conflicts with existing extents
when caching extents. In the future, we will add checks when caching
extents, which will trigger a warning. Therefore, Do not cache extents
that are being split. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/apic: Disable x2apic on resume if the kernel expects so
When resuming from s2ram, firmware may re-enable x2apic mode, which may have
been disabled by the kernel during boot either because it doesn't support IRQ
remapping or for other reasons. This causes the kernel to continue using the
xapic interface, while the hardware is in x2apic mode, which causes hangs.
This happens on defconfig + bare metal + s2ram.
Fix this in lapic_resume() by disabling x2apic if the kernel expects it to be
disabled, i.e. when x2apic_mode = 0.
The ACPI v6.6 spec, Section 16.3 [1] says firmware restores either the
pre-sleep configuration or initial boot configuration for each CPU, including
MSR state:
When executing from the power-on reset vector as a result of waking from an
S2 or S3 sleep state, the platform firmware performs only the hardware
initialization required to restore the system to either the state the
platform was in prior to the initial operating system boot, or to the
pre-sleep configuration state. In multiprocessor systems, non-boot
processors should be placed in the same state as prior to the initial
operating system boot.
(further ahead)
If this is an S2 or S3 wake, then the platform runtime firmware restores
minimum context of the system before jumping to the waking vector. This
includes:
CPU configuration. Platform runtime firmware restores the pre-sleep
configuration or initial boot configuration of each CPU (MSR, MTRR,
firmware update, SMBase, and so on). Interrupts must be disabled (for
IA-32 processors, disabled by CLI instruction).
(and other things)
So at least as per the spec, re-enablement of x2apic by the firmware is
allowed if "x2apic on" is a part of the initial boot configuration.
[1] https://uefi.org/specs/ACPI/6.6/16_Waking_and_Sleeping.html#initialization
[ bp: Massage. ] |
| In the Linux kernel, the following vulnerability has been resolved:
ceph: supply snapshot context in ceph_zero_partial_object()
The ceph_zero_partial_object function was missing proper snapshot
context for its OSD write operations, which could lead to data
inconsistencies in snapshots.
Reproducer:
../src/vstart.sh --new -x --localhost --bluestore
./bin/ceph auth caps client.fs_a mds 'allow rwps fsname=a' mon 'allow r fsname=a' osd 'allow rw tag cephfs data=a'
mount -t ceph fs_a@.a=/ /mnt/mycephfs/ -o conf=./ceph.conf
dd if=/dev/urandom of=/mnt/mycephfs/foo bs=64K count=1
mkdir /mnt/mycephfs/.snap/snap1
md5sum /mnt/mycephfs/.snap/snap1/foo
fallocate -p -o 0 -l 4096 /mnt/mycephfs/foo
echo 3 > /proc/sys/vm/drop/caches
md5sum /mnt/mycephfs/.snap/snap1/foo # get different md5sum!! |
