CVE-2026-12003
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
'....Modulessetup.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.
https://nvd.nist.gov/vuln/detail/CVE-2026-12003
Categories
CWE-427 : Uncontrolled Search Path Element
References
af854a3a-2127-422b-91ae-364da2661108
cna@python.org
AFFECTED (from MITRE)
| Vendor |
Product |
Versions |
| Python Software Foundation |
CPython |
|
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. |
CPE
REMEDIATION
EXPLOITS
Exploit-db.com
| id |
description |
date |
|
| No known exploits |
POC Github
Other Nist (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
description |
severity |
| 38 |
Leveraging/Manipulating Configuration File Search Paths
This pattern of attack sees an adversary load a malicious resource into a program's standard path so that when a known command is executed then the system instead executes the malicious component. The adversary can either modify the search path a program uses, like a PATH variable or classpath, or they can manipulate resources on the path to point to their malicious components. J2EE applications and other component based applications that are built from multiple binaries can have very long list of dependencies to execute. If one of these libraries and/or references is controllable by the attacker then application controls can be circumvented by the attacker. |
Very High |
| 471 |
Search Order Hijacking
An adversary exploits a weakness in an application's specification of external libraries to exploit the functionality of the loader where the process loading the library searches first in the same directory in which the process binary resides and then in other directories. Exploitation of this preferential search order can allow an attacker to make the loading process load the adversary's rogue library rather than the legitimate library. This attack can be leveraged with many different libraries and with many different loading processes. No forensic trails are left in the system's registry or file system that an incorrect library had been loaded. [Identify target general susceptibility] An attacker uses an automated tool or manually finds whether the target application uses dynamically linked libraries and the configuration file or look up table (such as Procedure Linkage Table) which contains the entries for dynamically linked libraries. [Craft malicious libraries] The attacker uses knowledge gained in the Explore phase to craft malicious libraries that they will redirect the target to leverage. These malicious libraries could have the same APIs as the legitimate library and additional malicious code. [Redirect the access to libraries to the malicious libraries] The attacker redirects the target to the malicious libraries they crafted in the Experiment phase. The attacker will be able to force the targeted application to execute arbitrary code when the application attempts to access the legitimate libraries. |
Medium |
MITRE
Techniques
| id |
description |
| T1574.001 |
Hijack Execution Flow:DLL search order hijacking |
| T1574.004 |
Hijack Execution Flow: Dylib Hijacking |
| T1574.007 |
Hijack Execution Flow:Path Interception by PATH Environment Variable |
| T1574.008 |
Hijack Execution Flow:Path Interception by Search Order Hijacking |
| T1574.009 |
Hijack Execution Flow: Path Interception by Unquoted Path |
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. |
Mitigations
| id |
description |
| M1044 |
Disallow loading of remote DLLs. This is included by default in Windows Server 2012+ and is available by patch for XP+ and Server 2003+.
Enable Safe DLL Search Mode to force search for system DLLs in directories with greater restrictions (e.g. <code>%SYSTEMROOT%</code>)to be used before local directory DLLs (e.g. a user's home directory)
The Safe DLL Search Mode can be enabled via Group Policy at Computer Configuration > [Policies] > Administrative Templates > MSS (Legacy): MSS: (SafeDllSearchMode) Enable Safe DLL search mode. The associated Windows Registry key for this is located at <code>HKLMSYSTEMCurrentControlSetControlSession ManagerSafeDLLSearchMode</code> |
| M1022 |
Set directory access controls to prevent file writes to the search paths for applications, both in the folders where applications are run from and the standard dylib folders. |
| M1022 |
Ensure that proper permissions and directory access control are set to deny users the ability to write files to the top-level directory <code>C:</code> and system directories, such as <code>C:Windows</code>, to reduce places where malicious files could be placed for execution. Require that all executables be placed in write-protected directories. |
| M1022 |
Ensure that proper permissions and directory access control are set to deny users the ability to write files to the top-level directory <code>C:</code> and system directories, such as <code>C:Windows</code>, to reduce places where malicious files could be placed for execution. Require that all executables be placed in write-protected directories. |
| M1022 |
Ensure that proper permissions and directory access control are set to deny users the ability to write files to the top-level directory <code>C:</code> and system directories, such as <code>C:Windows</code>, to reduce places where malicious files could be placed for execution. Require that all executables be placed in write-protected directories. |
| © 2022 The MITRE Corporation. Esta obra se reproduce y distribuye con el permiso de The MITRE Corporation. |
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
Discover this offer
