Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Requires legacy all-users install at OS-root-adjacent default path (AC:H), low-privileged local account (AV:L, PR:L), and a privileged user must actively run Python (UI:R), with scope change enabling code execution as that user (S:C).
Primary rating from Vendor (PSF).
CVSS VectorVendor: PSF
Lifecycle Timeline
2DescriptionCVE.org
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 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.
AnalysisAI
Privilege escalation in CPython on Windows enables a low-privileged local user to hijack the module search path of a more-privileged Python process running from a legacy all-users installation, enabling arbitrary code execution under an elevated context. The root cause is a VPATH-based fallback landmark mechanism compiled into release builds: on Windows, VPATH resolves two directory levels above PCbuild/, placing the Modules/Setup.local landmark outside the install directory in a location writable by unprivileged users under the legacy EXE installer's default all-users path. No public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV; however, high confidentiality and integrity impact (VC:H/VI:H) reflect the ability to fully substitute Python's module loading path.
Technical ContextAI
CPython's path initialization subsystem (Modules/getpath.py) uses two ordered mechanisms to determine whether the interpreter is running from a source tree: a primary landmark file pybuilddir.txt, and a fallback BUILD_LANDMARK resolving to Modules/Setup.local via the VPATH compile-time variable. On Windows, VPATH is set to '..\..' relative to the PCbuild/ output directory, so the fallback landmark resolves two directories above the python.exe install location. Under the legacy EXE all-users installer (historically defaulting to C:\PythonXY\), this places the landmark at C:\Modules\Setup.local - on the root of the OS drive, where Windows grants all authenticated users the CreateFolder permission by default. CWE-427 (Uncontrolled Search Path Element) precisely characterizes the flaw: the application incorporates an externally controllable path element (VPATH-derived) when locating trusted resources, allowing an adversary to redirect the interpreter's module discovery. The CPE cpe:2.3:a:python_software_foundation:cpython:*:*:*:*:*:*:*:* covers all CPython versions, though practical exploitation is confined to Windows legacy all-users installs. The fix confirmed in upstream PR #151545 removes the BUILD_LANDMARK fallback entirely from Modules/getpath.py and adds a dummy pybuilddir.txt in Makefile.pre.in, making the primary landmark the sole source-tree indicator.
RemediationAI
The upstream fix is available as PR https://github.com/python/cpython/pull/151545, which removes the VPATH-based BUILD_LANDMARK fallback from Modules/getpath.py and ensures pybuilddir.txt is the sole source-tree indicator; updated legacy installers will be released for Python 3.13 and 3.14 only. Users on earlier versions must apply the source patch and rebuild. The vendor's primary recommended mitigation is to migrate from the legacy EXE installer to the new Python install manager (https://www.python.org/downloads/latest/pymanager/), which defaults to per-user installation and eliminates the vulnerable directory permission model entirely. As a compensating control before migration, administrators can preemptively create the directory two levels above the Python installation (e.g., C:\Modules\ for an install at C:\Python313\) and apply restrictive ACLs preventing unprivileged users from writing there; this blocks the attacker from placing the landmark but must be applied before any attacker creates the directory, and requires knowing the exact install path for each Python version. Alternatively, restricting non-admin write access to the OS drive root (C:\) removes the underlying Windows permission that enables the attack, though this may break legacy application compatibility that depends on drive-root writability.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Same weakness CWE-427 – Uncontrolled Search Path Element
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-37125
GHSA-2wqx-fp26-qh5v