CVE Database

The AsyncHttpClient library allows Java applications to execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, PropertiesBasedResumableProcessor stores resumable download state at the predictable shared path $java.io.tmpdir/ahc/ResumableAsyncHandler.properties with default permissions and link-following file operations. A local user who can read the shared store can see download URLs, including embedded user information or query tokens. A local user who can write within or pre-create the affected shared store directory can plant a symbolic link that the client follows when saving state, truncating and overwriting a target file writable by the client process. The filesystem path is used when ResumableAsyncHandler decorates another AsyncHandler, while the no-argument constructors use a no-op processor and are unaffected. This issue is fixed in versions 2.16.1 and 3.0.12.

An unix symbolic link (symlink) following vulnerability has been reported to affect Qsync Central. If a remote attacker gains a user account, they can then exploit the vulnerability to compromise the security of the system. We have already fixed the vulnerability in the following version: Qsync Central 5.0.0.7 and later Qsync Central 5.1.0.3 and later Qsync Central 5.2.0.5 and later Qsync Central 5.3.0.2 and later

ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-32, delegate symlink cleanup does not check the MAGICK_SHRED_PASSES environment variable, allowing a local privileged workflow to overwrite a file with random data. This issue is fixed in version 7.1.2-32.

A flaw was found in source-to-image. When unpacking archive files, the application fails to properly sanitize symbolic links pointing to absolute file paths. An attacker who supplies a malicious builder image can exploit this vulnerability by embedding links pointing outside the extraction directory. This allows the attacker to bypass sandbox boundaries, potentially leading to unauthorized information disclosure or file modification on the host system.

In Flatpak before 1.18.1, a malicious sandboxed app can replace ~/.var/app/$appid/.ld.so with a symlink, causing regenerate_ld_cache to write files at an arbitrary location. The filenames and content are not attacker controlled, making this hard to exploit.

A flaw was found in cockpit-files. A low-privileged local user can exploit this vulnerability by crafting a directory containing a symbolic link (symlink) and then using the privileged "Paste as owner" function. This allows for arbitrary file ownership changes outside the intended pasted directory, leading to a compromise of data integrity. In some cases, this could also lead to reduced confidentiality if the new ownership grants unauthorized read access. Exploitation requires user interaction to select a non-original owner during the paste operation.

A symlink-following flaw was found in libvirt's qemuTPMEmulatorPrepareHost() function. The function uses a path-based chown() on the swtpm logfile without checking for symbolic links. A local attacker with access to the swtpm account can replace the logfile with a symlink, causing libvirtd (running as root) to transfer ownership of an arbitrary file to the swtpm user.

In the opam package before 2.5.2 for OCaml, the sandbox protection mechanism can be bypassed because symlinks are mishandled during use of .install files.

UNIX symbolic link (symlink) following vulnerability in ilya-zlobintsev/LACT allows for local denial-of-service. This issue affects LACT: through 0.10.0.

crun is an open source OCI Container Runtime fully written in C. Prior to version 1.28, crun's default device setup opens the container rootfs `/dev` directory without `O_NOFOLLOW`. If an OCI bundle contains `rootfs/dev` as a symlink and the bundle configuration does not mount `/dev`, crun follows that symlink and creates the default device nodes and stdio symlinks at the symlink target outside the container rootfs. In a local rootful crun replay, this created fixed device nodes and symlinks outside the rootfs before crun returned failure. A pre-existing file named `ptmx` in the target directory was also replaced by crun's forced `ptmx -> pts/ptmx` symlink. Version 1.28 fixes the issue.

pdm is a Python package and dependency manager supporting the latest PEP standards. In versions prior to 2.27.0, pdm writes several project-local state or configuration files without symlink protection. If a malicious repository places those files as symlinks, local PDM operations can overwrite the symlink targets. This creates an arbitrary file clobber primitive relative to the privileges of the invoking user. Config.__init__() resolves the project-local pdm.toml path and _save_config() writes to the resolved target. If PROJECT_ROOT/pdm.toml is a symlink to another file, pdm config -l ... updates the target file instead of refusing the write. The same general problem exists for other project-local persistence paths that are written directly with no lstat / O_NOFOLLOW protection. For the pdm.toml PoC specifically, the target file must already contain parseable TOML. Otherwise the load step fails before the write path is reached. That parser constraint does not apply to the .pdm-python or .python-version sinks. This issue has been fixed in version 2.27.0.