| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| To allow builds of Python to be run from an in-tree layout (rather than
an installed file layout), the VPATH variable is defined at build time
and used to locate certain landmarks - specifically,
Modules/setup.local. When this landmark is found relative to VPATH
relative to the executable, Python assumes it is running in a source
tree and generates a different default sys.path. This code remains in
release builds, so that release-ready builds can be built in-tree.
On Windows, since builds are written to 'PCbuild/', the value of
VPATH is set to '..\..', which results in a landmark of
'..\..\Modules\setup.local'. This path is outside the install directory
of Python, and may have different permissions, potentially allowing a
low-privilege user to create the landmark and an alternative `Lib`
folder that will be discovered by an otherwise restricted install.
Such a setup occurs with the legacy default install location for all
users (in the now superseded EXE installer), due to how Windows allows
all users to create folders in the root directory of their OS drive.
Our recommended mitigation on Windows is to migrate away from the
legacy installer and use the new [Python install
manager](https://www.python.org/downloads/latest/pymanager/) to install
for the current user. Installs where the directory two levels above the
Python installation directory have equivalent permissions are unaffected
(in general, a per-user install cannot be modified at all by other
users, removing any escalation of privilege risk, and could be directly
modified by a privileged user, making the potential tampering
irrelevant). Alternative mitigations might include preemptively creating
and restricting access to a `Modules` directory. Be aware that only 3.13
and 3.14 will receive updated legacy installers - earlier fixes are only
provided as sources.
Platforms other than Windows allow VPATH to be overridden, but as they
don't usually use a separated directory in the build for binaries, are
unlikely to have a landmark reference outside of the install directory.
The landmark detection involving VPATH is a fallback for when a more
specific landmark - .\pybuilddir.txt - is absent, and was included for
compatibility. Future releases of Python will no longer include the
fallback, and so builds will need to generate or preserve the
pybuilddir.txt file in order to work in-tree. This landmark file has
been generated on Windows since 3.11, and on other platforms for longer. |
| Local privilege escalation by loading DLLs from a shared temporary directory in ANSSI’s DFIR-ORC, versions 10.2.7 and prior. An attacker with prior access to the system, can place a malicious DLL in C:\Windows\Temp and wait for the application to be executed. Because DFIR-ORC is extracted and executed from that location with administrative privileges, the malicious library can be loaded automatically, allowing the attacker to gain administrator privileges on the affected machine. |
| Dell Peripheral Manager, versions from 1.5.1 to 1.7.2, contain an uncontrolled search path element vulnerability. An attacker could potentially exploit this vulnerability through preloading malicious executable, leading to arbitrary code execution. |
| Dell Peripheral Manager, versions prior to 1.7.3, contain an uncontrolled search path element vulnerability. An attacker could potentially exploit this vulnerability through preloading malicious dll., leading to arbitrary code execution. |
| IBM i 7.6, 7.5, 7.4, and 7.3 could allow a user to gain elevated privileges due to an unqualified library call. A malicious actor could cause user-controlled code to run with administrator privilege. |
| MobaXterm Personal Edition (Portable), in its 26.3 version (Build 5154), allows arbitrary code execution by loading malicious DLLs from a temporary directory that is predictable and can be modified by the user. During startup, the application searches for specific DLLs in this location before resorting to the system’s secure paths, enabling an attacker with local access to place a specially crafted DLL to be executed automatically when the victim launches the application. |
| MobaXterm Personal Edition (Portable), in its 26.3 version (Build 5154), allows arbitrary code execution by loading a malicious DLL located in the same directory as the portable executable. Because the application automatically loads the winspool.drv library from that location during startup, an attacker with local access can place a specially crafted DLL alongside the executable to be executed when the victim launches the application. |
| OpenClaw before 2026.4.25 contains a path traversal vulnerability in memory-core artifact loading where workspace state influences local package root resolution. Attackers with access to affected workspaces can load memory-core artifacts from unintended local locations, potentially executing malicious code or accessing sensitive data. |
| A local privilege escalation vulnerability exists in Check Point Identity Agent Full for Windows OS. An authenticated local user may be able to execute arbitrary code with SYSTEM privileges due to improper handling of executable resolution during the log collection process. Successful exploitation could allow an attacker to gain elevated privileges on the affected Windows endpoint. |
| A potential uncontrolled search path vulnerability was reported in the LanSchool Classic client application that could allow a local authenticated user to execute arbitrary code with elevated privileges. |
| A DLL hijacking vulnerability in Wassimulator (GitHub) CactusViewer v2.3.0 allows attackers to escalate privileges and execute arbitrary code via a crafted DLL. |
| Emocheck insecurely loads Dynamic Link Libraries (DLLs). If a crafted DLL file is placed to the same directory, an arbitrary code may be executed with the privilege of the user invoking EmoCheck. |
| Moby is an open source container framework. In versions prior to 29.5.1 and in moby/moby v2 prior to v2.0.0-beta.14, when a compressed archive is uploaded to a container via `PUT /containers/{id}/archive` or piped through `docker cp -`, the daemon resolves decompression binaries (such as `xz` or `unpigz`) from the container's filesystem rather than the host's due to incorrect ordering of operations. A malicious container image containing a trojanized decompression binary can achieve arbitrary code execution with full daemon privileges, including host root UID and unrestricted capabilities, when a user uploads a compressed (xz or gzip) archive into that container. This issue is fixed in Docker Engine 29.5.1 and moby/moby v2.0.0-beta.14. Workarounds include only running containers from trusted images, using authorization plugins to restrict access to the `PUT /containers/{id}/archive` endpoint, and avoiding piping compressed archives into containers created from untrusted images |
| Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis DeviceLock DLP (Windows) before build 9.0.15051.93227. |
| Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis DeviceLock DLP (Windows) before build 9.0.15051.93227. |
| Local privilege escalation due to EXE hijacking vulnerability. The following products are affected: Acronis DeviceLock DLP (Windows) before build 9.0.15051.93227. |
| Claude HUD through 0.0.12, patched in commit 234d9aa, contains a command injection vulnerability that allows local attackers to execute arbitrary commands by manipulating the COMSPEC environment variable. Attackers can set COMSPEC to an arbitrary binary path before claude-hud performs its version check, causing execFile() to execute the attacker-supplied executable with cmd.exe arguments, resulting in arbitrary code execution on Windows systems. |
| An uncontrolled search path element vulnerability in Synology Presto Client before 2.1.3-0672 allows local users to read or write arbitrary files and conduct denial-of-service during installation by placing a malicious DLL in advance in the same directory as the installer. |
| Espressif Shared GitHub DangerJS is a reusable GitHub Action CI DangerJS workflow for Espressif GitHub projects. Prior to 1.0.1, the action's entrypoint.sh invoked DangerJS from the caller's workspace after copying the fork's checkout into it, creating an untrusted search path for both binary resolution and Node.js module resolution. A fork pull request processed by a pull_request_target workflow could therefore cause fork-supplied code to execute inside the action container in place of the action's own code. This vulnerability is fixed in 1.0.1. |
| pam_usb provides hardware authentication for Linux using ordinary removable media. Prior to 0.9.0, multiple pam_usb helper tools resolved external binaries through the PATH environment variable rather than using absolute paths. An attacker who can influence the process environment during PAM authentication or tool execution could substitute malicious binaries. The affected tools are pamusb-check (src/tmux.c), pamusb-conf (tools/pamusb-conf), and pamusb-keyring-unlock-gnome (tools/pamusb-keyring-unlock-gnome). This vulnerability is fixed in 0.9.0. |
