CVE-2026-45491
Improper link resolution before file access ('link following') in .NET allows an unauthorized attacker to perform tampering locally.
CVSS
6.2
Medio
EPSS
0.4%
p33
KEV
—
Exploit Today
10
0-100
Publicado: 9 jun 2026 · Última mod.: 23 jul 2026 · CWE-59
0.4%EPSS · 30 días0.4%
2026-08-242026-09-21
Improper link resolution before file access ('link following') in .NET allows an unauthorized attacker to perform tampering locally.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-55074——
——0Ansible 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.22hCVE-2026-92253—3.1%
——1Improper 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.23hCVE-2026-158158.8 ALT56.7%
——17Grafana 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.3dCVE-2026-54587—1.0%
——0mport 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.5dCVE-2026-54576—1.0%
——0mport 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.4dCVE-2026-868615.9 MED37.5%
——11pgAdmin 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.21h