| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| When tarfile extracts a link on a system that doesn't support links, it falls back to extracting a member from the archive. In this case, the filter function is run twice: once for the extracted member, and once with name set to the location of the link. For one of the calls, the return value was ignored. Instead, the member should be skipped if either call returns None. |
| Ansible FreeBSD Jail Connection Plugin is an Ansible connection plugin for FreeBSD Jails via jexec. Through version 1.3.0, the jailexec connection plugin's put_file resolved a transfer's destination to a path on the jail host ( + ) and ran mkdir -p and mv there as root on the host. Those commands follow symbolic links, and the path was operated on outside the jail, so a symlink existing inside the jail was followed by the host-side, root-privileged mv. A party controlling content inside a managed jail (the jail's root, or any process able to create a symlink in a directory an Ansible task later writes to) can therefore cause an arbitrary root-owned write on the host, outside the jail — a full jail escape. Arbitrary root-owned host writes are readily escalated to host compromise (e.g. cron, rc.d, authorized_keys). Preconditions for this vulnerability are that the operator runs a copy/template/fetch-style task (anything using put_file) against the jail, and the attacker can place a symlink inside the jail at or above the task's destination before the transfer runs. This issue has been fixed in version 2.0.0. |
| Dell Update Package Framework, versions prior to 26.07.03, contains an Improper Link Resolution Before File Access ('Link Following') vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Filesystem access for attacker. |
| Dell Update Package Framework, versions prior to 26.07.03, contains an Improper Link Resolution Before File Access ('Link Following') vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Filesystem access for attacker. |
| pgAdmin 4's File Manager save_file endpoint, which backs saving from the Query Tool and ERD, validated the requested path with Filemanager.check_access_permission() and then opened the file for writing with a plain open() call. CVE-2026-7819 had previously hardened the separate file upload path by opening its target with O_NOFOLLOW, so that the kernel refuses to follow a symbolic link at the final path component, but save_file was left on an unprotected open(). A symbolic link already present when the check ran was rejected by the check itself; the remaining exposure was a link substituted at the final path component in the interval between the check and the write, at which point the write followed the link and landed outside the user's storage directory, creating or overwriting an arbitrary file as the operating-system account running pgAdmin.
Exploitation requires the ability to create or replace a symbolic link inside the requesting user's storage directory. pgAdmin exposes no interface that creates symbolic links, so this requires filesystem access to the pgAdmin host or to a shared or network-mounted storage backend, together with winning the timing window. The reporter did not achieve a write against a released version, having attempted approximately 63,000 racing requests without success; the reported defect is the uncovered write path rather than a demonstrated sandbox escape.
The fix routes save_file's write through the same O_NOFOLLOW-protected helper already used by the upload path, so both File Manager write sinks carry identical kernel-enforced protection, and reports a symbolic-link refusal explicitly instead of surfacing the underlying system error text. Note that files created by save_file are now given mode 0600, inheriting the behaviour introduced for uploads. The protection covers the final path component; substitution of an intermediate directory component is not addressed by this change.
This issue affects pgAdmin 4: from the introduction of the containment check in the File Manager save path before 9.18. |
| Improper link resolution before file access in the quarantine restoration process of WatchDog Anti-Virus 1.8.640 on Windows allows local, low-privileged attackers to cause a quarantined file to be written to an arbitrary filesystem location by creating a directory junction at the original file path and persuading an administrator to restore the file. This may enable modification of protected files or SYSTEM-level code execution through DLL hijacking. |
| A symlink following vulnerability was found in the ABRT post-create event handler scripts in libreport. Event scripts write output files using shell redirections without the O_NOFOLLOW flag. If the target file is replaced with a symlink, the shell process running as root follows the symlink and writes content to the symlink target, allowing arbitrary file overwrites on the system. |
| A flaw was found in libvirt. A local attacker, specifically a process running as the confined `swtpm` user, could exploit a symlink-following vulnerability in the `virFileChownFiles()` function. By planting a symbolic link within the `swtpm` state directory, the attacker could trick the root-level libvirt daemon into changing the ownership of an arbitrary file to the `swtpm` user. This allows for privilege escalation from the `swtpm` sandbox to root-level file ownership control. |
| This issue was addressed with improved handling of symlinks. This issue is fixed in macOS Golden Gate 27. An app may be able to break out of its sandbox. |
| ImageMagick before 7.1.2-30 and 6.9.13-55 contains a time-of-check-time-of-use (TOCTOU) vulnerability in the video decoder that allows attackers to bypass path policy write restrictions via symlink swaps. An attacker can replace a symlink between policy validation (check-time) and the file write operation (use-time) to write to policy-denied locations. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed
A potential invalid storage access issue can occur after replacing a
cgroup bpf prog.
This occurs in the following scenario:
1. prog1 with storage is attached to a cgroup in multi-attach mode.
2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach
mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or
update_effective_progs).
3. A new prog3 is attached to the cgroup in multi-attach mode.
The reason is that __cgroup_bpf_attach overwrites pl->storage with the
new storage prior to attachment completion. When attachment fails
midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to
free the newly allocated storage, but fails to restore pl->storage back
to old_storage.
Consequently, the still-active prog1 holds invalid or dangling storage
pointers, leading to an invalid memory access when prog1 executes and
calls bpf_get_local_storage. Additionally, original pl->flags and
cgrp->bpf.flags[atype] are left unrestored.
Fix this by saving old_pl_flags, old_storage, and old_flags prior to the
update, and properly restoring all of them in the cleanup path on error. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: asus: refactor the two workqueues and init sequence
Multiple issues have been found within the hid-asus driver:
- unchecked size in asus_raw_event()
- unclean teardown of asus_probe on failure
- possible use-after-free in asus_probe
- multiple workqueue used for jobs where one was enough
- sleeping calls in atomic context
- packets of incorrect size being sent to the keyboard controller
Join the two workqueues into one reusing the stopping mechanism
of the brightness workqueue, use the joined workqueue to also
move the asus_wmi_send_event() sleeping call away from atomic
context and add a size check in asus_raw_event(). |
| Grafana OSS and Grafana Enterprise did not safely resolve symbolic links when
extracting plugin archives. A crafted plugin archive can chain relative symbolic link
entries to escape the plugin installation directory, writing arbitrary files and an
executable backend binary outside that directory. The dropped executable runs with the
privileges of the Grafana server process, resulting in remote code execution.
Plugin archives are extracted before their signature is verified, so a valid plugin
signature does not prevent the write. An operator can therefore be affected by
installing a plugin that appears legitimate, as well as by installing a plugin from an
arbitrary archive using grafana-cli, the GF_INSTALL_PLUGINS environment variable, or
preinstall configuration.
Grafana Enterprise is affected because it includes the same plugin extraction code as
Grafana OSS. |
| Composer is a dependency Manager for the PHP language. From 1.0 until 2.2.30 and from 2.3.0 until 2.10.3, a malicious or compromised dependency can bypass the earlier CVE-2026-59946 binary-path hardening because Composer validates literal parent-directory segments only during dependency resolution, while the symlink and installed-metadata paths described by the advisory skip that validation. A package can ship an in-package binary symlink that resolves outside its installation directory, or attacker-influenced vendor/composer/installed.json metadata can provide an escaping binary path during a reinstall or regeneration of missing vendor/bin entries. The installed-metadata path is reachable only when the vendor directory was not populated by the same validated install run, such as when it is restored from an untrusted cache, copied from an earlier build stage, carried over from an older Composer run, or writable by a lower-trust build step. Composer can follow the path, change the external target's permissions to make it world-readable and executable, and create a runnable vendor/bin proxy to that external file. The issue does not directly read or transmit data and does not by itself provide remote code execution. This issue is fixed in versions 2.2.30 and 2.10.3. |
| mport is the MidnightBSD Package Manager. Prior to 2.7.8, directory assets handled as ASSET_DIR or ASSET_DIR_OWNER_MODE in libmport/bundle_read_install_pkg.c used path-based mport_mkdirp(), ownership, and permission operations. A local attacker able to modify part of the target installation tree could use dot-dot traversal or substitute symlinks during privileged package installation, causing directory creation or attribute changes to affect attacker-selected paths outside the intended package directories. This issue is fixed in version 2.7.8. |
| mport is the MidnightBSD Package Manager. Prior to 2.7.8, do_actual_install() in libmport/bundle_read_install_pkg.c used path-based lstat(), chown(), stat(), and chmod() operations while installing package files. A local attacker with write access to a target directory could replace a checked file with a symlink before privileged ownership or mode changes were applied, redirecting those changes to an attacker-selected path and compromising filesystem integrity or permissions. This issue is fixed in version 2.7.8. |
| An insufficient check allowed for the overwrite of arbitrary files via a symlink. |
| In the Linux kernel, the following vulnerability has been resolved:
media: video-i2c: fix kthread error pointer left in kthread_vid_cap on failure
kthread_run() returns an ERR_PTR on failure, not NULL.
When start_streaming() fails, data->kthread_vid_cap is left holding
this error pointer instead of being cleared.
This causes two subsequent bugs:
1. A future call to start_streaming() sees a non-NULL kthread_vid_cap
and returns 0 (success) immediately, without actually starting the
capture thread.
2. A call to stop_streaming() checks 'kthread_vid_cap == NULL' which
is false for an error pointer, and proceeds to call kthread_stop()
on the error pointer, leading to a kernel crash.
Fix this by resetting kthread_vid_cap to NULL on failure before
jumping to the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
cpuidle: dt_idle_genpd: kfree() the original name allocation
dt_idle_pd_alloc() kasprintf()s the full node path, then points
pd->name at kbasename() of that string. dt_idle_pd_free() kfree()s
pd->name, which is no longer the start of the allocation.
Copy the basename instead. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix memory corruption by not reinjecting CK machine checks
Channel-subsystem damage machine checks are for the host channel
subsystem. The guest channel subsystem is emulated in the userspace VMM.
There is no point in forwarding such machine checks into the guest.
This also simplifies the machine check reinjection and avoids kfree of a
stack variable as reported by sashiko. There might be still machine
checks that have the ck bit set with another bit (like instruction
damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and
ED bits already are. |
