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.

According to the versions of the python3 packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

    unicodedata.normalize() can take excessive CPU time when processing_x000D_     specially crafted Unicode input containing long runs of combining characters_x000D_     with alternating Canonical Combining Class values._x000D_     This affects all normalization forms.(CVE-2026-3276)

    tarfile.extractall() with the 'data' or 'tar' filter could be bypassed by a crafted archive where a     hardlink references a symlink stored at a deeper name than the hardlink itself. The extraction fallback     validated the symlink at its archived location but recreated it at the hardlink's shallower path, letting     a relative target the filter judged contained escape the destination directory. This allowed a malicious     tar archive to create a symlink pointing outside the destination, enabling out-of-destination file reads     or writes. This was an incomplete fix of CVE-2025-4330.(CVE-2026-11940)

    When calling base64.b64decode() or related functions the decoding process would stop after encountering     the first padded quad regardless of whether there was more information to be processed. This can lead to     data being accepted which may be processed differently by other implementations. Use 'validate=True' to     enable stricter processing of base64 data.(CVE-2026-3446)

    In the Tarfile.extract() function, the filter parameter is not passed properly when extracting hardlinks.
    An affected system that extracts content from untrusted tar files could end up writing files with an     unexpected uid/gid despite the user passing filter='data' to the extract() function.(CVE-2026-4360)

    The imaplib module, when passed a user-controlled command, can have additional commands injected using     newlines. Mitigation rejects commands containing control characters.(CVE-2025-15366)

    To allow builds of Python to be run from an in-tree layout (rather than_x000D_     an installed file layout), the VPATH variable is defined at build time_x000D_     and used to locate certain landmarks - specifically,_x000D_     Modules/setup.local. When this landmark is found relative to VPATH_x000D_     relative to the executable, Python assumes it is running in a source_x000D_     tree and generates a different default sys.path. This code remains in_x000D_     release builds, so that release-ready builds can be built in-tree._x000D_
    _x000D_     On Windows, since builds are written to 'PCbuild/', the value of_x000D_     VPATH is set to '..\..', which results in a landmark of_x000D_     '..\..\Modules\setup.local'. This path is outside the install directory_x000D_     of Python, and may have different permissions, potentially allowing a_x000D_     low-privilege user to create the landmark and an alternative `Lib`_x000D_     folder that will be discovered by an otherwise restricted install._x000D_
    _x000D_     Such a setup occurs with the legacy default install location for all_x000D_     users (in the now superseded EXE installer), due to how Windows allows_x000D_     all users to create folders in the root directory of their OS drive._x000D_
    _x000D_     Our recommended mitigation on Windows is to migrate away from the_x000D_     legacy installer and use the new [Python install_x000D_     manager](https://www.python.org/downloads/latest/pymanager/) to install_x000D_     for the current user. Installs where the directory two levels above the_x000D_     Python installation directory have equivalent permissions are unaffected_x000D_     (in general, a per-user install cannot be modified at all by other_x000D_     users, removing any escalation of privilege risk, and could be directly_x000D_     modified by a privileged user, making the potential tampering_x000D_     irrelevant). Alternative mitigations might include preemptively creating_x000D_     and restricting access to a `Modules` directory. Be aware that only 3.13_x000D_     and 3.14 will receive updated legacy installers - earlier fixes are only_x000D_     provided as sources._x000D_
    _x000D_     Platforms other than Windows allow VPATH to be overridden, but as they_x000D_     don't usually use a separated directory in the build for binaries, are_x000D_     unlikely to have a landmark reference outside of the install directory._x000D_
    _x000D_     The landmark detection involving VPATH is a fallback for when a more_x000D_     specific landmark - .\pybuilddir.txt - is absent, and was included for_x000D_     compatibility. Future releases of Python will no longer include the_x000D_     fallback, and so builds will need to generate or preserve the_x000D_     pybuilddir.txt file in order to work in-tree. This landmark file has_x000D_     been generated on Windows since 3.11, and on other platforms for longer.(CVE-2026-12003)

    `xml.parsers.expat` and `xml.etree.ElementTree` use insufficient entropy for Expat hash-flooding     protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this     vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.(CVE-2026-7210)

    When using the 'configparser' module to write configuration files_x000D_     containing multi-line text values with carriage return characters (\r) the_x000D_     resulting file could be injected with unexpected keys and values if the_x000D_     attacker controls the written value.(CVE-2026-0864)

    When using the 'tarfile' module with a file opened in 'streaming mode' (mode='r|') the tarfile module did     not properly handle EOF, making archive parsing take exponentially longer.(CVE-2026-11972)

    The Oracle Solaris Third Party Bulletin announces patches for one or more security vulnerabilities     addressed in third party software that is included in Oracle Solaris distributions. Starting January 20,     2015, Third Party Bulletins are released on the same day when Oracle Critical Patch Updates are released.
    These bulletins will also be updated after their release between the quarterly Critical Patch Updates. In     addition, Third Party Bulletins may also be updated for vulnerability issues deemed too critical to wait     for the next monthly update.(CVE-2026-8328)

    The incremental HTML parser (html.parser.HTMLParser) allows for CPU_x000D_     denial-of-service through repeated unterminated markup declarations when_x000D_     processing uncontrolled data.(CVE-2026-15308)

Tenable has extracted the preceding description block directly from the EulerOS python3 security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-12003)

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1790155146 advisory.

  - 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. (CVE-2026-12003)

  - The stringprep module didn't 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 behavior would cause     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-17084)

  - The tarfile module's tar and data extraction filters created directories outside the destination for     members whose name leaves the destination and returns to it, such as ../evil/../dest/sub/file. The     containment check used the resolved path, but intermediate directories were created from the name as     given. Only empty directories are created outside the destination. Member contents are still extracted     inside it. To return to the destination the member's name must contain the destination directory's own     final component, so extraction into a secure randomised directory is not affected. This affects POSIX     platforms only. On Windows, .. components are collapsed before the path reaches the filesystem, so the     directories outside the destination are never created. (CVE-2026-19672)

  - When tarfile extracts a link on a system that doesn't support links, it falls back to extracting a member     from the archive. In this case, the filter function is run twice: once for the extracted member, and once     with name set to the location of the link. For one of the calls, the return value was ignored. Instead,     the member should be skipped if either call returns None. (CVE-2026-87910)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-12003)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
364019	EulerOS 2.0 SP15 : python3 (EulerOS-SA-2026-4012)	Nessus	Huawei Local Security Checks	Local	high
364010	EulerOS 2.0 SP15 : python3 (EulerOS-SA-2026-3946)	Nessus	Huawei Local Security Checks	Local	high
463383	Echo: python3.13: security update to 3.13.5-2+e24	Tenable Cloud Security	Echo Local Security Checks	Local	medium
463383	Echo: python3.13: security update to 3.13.5-2+e24	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	medium
351910	AlmaLinux 9.2 [TuxCare] Security Update: python3.11 / python3.11-debug / python3.11-devel / python3.11-idle / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1790155146)	Nessus	Alma Linux Local Security Checks	Local	medium
321379	Linux Distros Unpatched Vulnerability : CVE-2026-12003	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-12003

medium

Tenable Plugins

high

high

medium

medium

medium

medium