CVE-2026-12003
MediumCVSS 5.3Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
CVE-2026-12003 vulnerability concerns how Python handles the VPATH variable during builds from the source tree. On Windows, VPATH may point to a location outside the Python installation directory, potentially allowing low-privilege users to create files that could be used to access an alternative `Lib` folder.
Risk Assessment
The risk associated with this vulnerability is the potential for privilege escalation by low-privilege users who may manipulate files in the system, leading to unauthorized access to Python resources.
Recommendation
It is recommended to migrate from the legacy installer to the new Python installation manager to install for the current user. Alternatively, preemptively creating and restricting access to a `Modules` directory may be considered.
Other vulnerabilities in Python
See all- CVE-2013-7338High
Python versions before 3.3.4 RC1 allow remote attackers to cause a denial of service via a file size value larger than the size of the zip file in functions related to reading and extracting zip files.
- CVE-2023-27043Medium
The email module in Python through 3.11.3 incorrectly parses email addresses containing special characters. The wrong portion of an RFC2822 header is identified as the value of the addr-spec.
- CVE-2023-24329High
A vulnerability in the urllib.parse component of Python before version 3.11.4 allows attackers to bypass blocklisting methods by supplying a URL that starts with blank characters.
- CVE-2026-1299Medium
The email module in Python, specifically the BytesGenerator class, improperly quotes newlines in email headers during serialization, allowing header injection. This only affects usage of LiteralHeader that does not respect email folding.
- CVE-2022-0391High
A flaw was found in Python's urllib.parse module where the urlparse method does not sanitize input, allowing characters like ' ' and ' ' in the URL path. This can lead to CRLF injection attacks.
- CVE-2022-42919High
A vulnerability in Python 3.9.x before 3.9.16 and 3.10.x before 3.10.9 on Linux allows local privilege escalation in a non-default configuration. The multiprocessing library with the forkserver start method permits pickle deserialization from any user on the same local network of the machine.
- CVE-2026-15310Low
When decompressing crafted zip files using the bzip/LZMA/Zstandard compressions, Python could use an attacker-controlled size to pre-allocate memory, possibly resulting in memory exhaustion.
- CVE-2026-17084Medium
The 'stringprep' module did not process characters from RFC 3454 tables B.2 or B.3 correctly: the latest Unicode codepoint attributes were used instead of the specified Unicode 3.2.0. This causes mismatches when processing domain names using IDNA 2003 (the 'idna' codec) and the in_table_b2() function of the 'stringprep' module. This only affects domain names containing characters that were not previously registered or had their Unicode attributes such as case-folding behavior updated since Unicode 3.2.0.
- CVE-2026-18503Low
A vulnerability in Python's csv.Sniffer where attacker-controlled CSV samples can trigger super-linear regular-expression work during dialect sniffing, consuming significant CPU.
- CVE-2026-15308High
The incremental HTML parser (html.parser.HTMLParser) allows CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.
Original NVD description (English source)
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.