Alan Coopersmith <alan.coopersmith () oracle com> writes: https://www.runsybil.com/blog/cpython-0-day-vulnerabilities-threaten-the-ai-supply-chain reports on a sandbox escape it found in CPython: The bug we discovered abuses CPython's handling of generic types to accomplish a breakout. We exploited it using objects that sandboxes make available in every template, even in empty sandbox contexts. (See the above URL for full details.)
They were not successful in reporting it as a security vulnerability: CPython’s stance on our memory bugs is documented, and was reiterated to us: > CPython does not support sandboxing untrusted Python code as a security > boundary, so escapes from such a sandbox are not vulnerabilities in > Python and should be reported to the sandbox’s developers instead. The maintainers of Jinja provided a response at odds with CPython’s guidance: > Report this to cpython. It's problem with cpython, not with Jinja. https://lwn.net/Articles/574215/ Instead they submitted a fix as https://github.com/python/cpython/pull/155761 but note that upstream is not backporting it to security releases. sam
https://www.runsybil.com/blog/cpython-0-day-vulnerabilities-threaten-the-ai-supply-chain reports on a sandbox escape it found in CPython: The bug we discovered abuses CPython's handling of generic types to accomplish a breakout. We exploited it using objects that sandboxes make available in every template, even in empty sandbox contexts. (See the above URL for full details.)
They were not successful in reporting it as a security vulnerability: CPython’s stance on our memory bugs is documented, and was reiterated to us:
> CPython does not support sandboxing untrusted Python code as a security > boundary, so escapes from such a sandbox are not vulnerabilities in > Python and should be reported to the sandbox’s developers instead.
The maintainers of Jinja provided a response at odds with CPython’s guidance:
> Report this to cpython. It's problem with cpython, not with Jinja. Instead they submitted a fix as https://github.com/python/cpython/pull/155761 but note that upstream is not backporting it to security releases.
-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris
tar filter allows writing outside destination via empty-named symlink
-------- Forwarded Message -------- Date: Wed, 30 Sep 2026 16:10:08 +0000 From: Seth Larson <seth () python org> Reply-To: security-sig () python org To: security-announce () python org
There is a CRITICAL severity vulnerability affecting CPython.
Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-19445 https://github.com/python/cpython/pull/158504
Security-announce mailing list -- security-announce () python org https://mail.python.org/mailman3//lists/security-announce.python.org
-------- Forwarded Message -------- Date: Wed, 30 Sep 2026 16:08:09 +0000 From: Seth Larson <seth () python org> Reply-To: security-sig () python org To: security-announce () python org
There is a HIGH severity vulnerability affecting CPython.
Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-19553 https://github.com/python/cpython/pull/158503 Security-announce mailing list -- security-announce () python org https://mail.python.org/mailman3//lists/security-announce.python.org
ssl.SSLContext.wrapbio() didn't require the serverhostname argument to not be None if ssl.SSLContext.checkhostname was set. Due to a missing parameter check in SSLObject, if the serverhostname argument isn't supplied then hostname verification would be silently skipped.
This defect could lead to programs where certificate hostname verification appeared to be succeeding with SSLContext.checkhostname = True and no ValueError being raised due to misconfiguration.
If the program passes a serverhostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability.
Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty serverhostname value to SSLContext.wrapbio(), asyncio.createconnection(), or asyncio.loop.starttls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrapsocket(), when serverhostname isn't supplied.
A remote, unauthenticated TLS client can make a server crash or call through a freed pointer if its snicallback assigns a different context to SSLSocket.context (the documented way to select a certificate per server name) and nothing else keeps the original ssl.SSLContext alive. Typical cases are servers that create an SSLContext per connection or replace it while connections are open; servers that wrap their listening socket with it are not affected.
Mitigation: keep a reference to every SSLContext that sets snicallback for the lifetime of the server. TLS clients are not affected.
Race condition in tempfile.TemporaryDirectory cleanup allows deleting files outside the temporary directory
In CPython 3.13 and earlier, the tarfile module's data and tar extraction filters are vulnerable to crafted archives containing a hard link to a symbolic link. Such archives may cause extraction to modify the permissions or modification time of a file outside the destination directory, or expose the contents of that file within the extracted tree.
In CPython 3.13 and earlier, the tarfile module's data and tar extraction filters are vulnerable to crafted archives containing a hard link to a symbolic link. Such archives may cause extraction to modify the permissions or modification time of a file outside the destination directory, or expose the contents of that file within the extracted tree.
In CPython 3.13 and earlier, the tarfile module's data and tar extraction filters are vulnerable to crafted archives containing a hard link to a symbolic link. Such archives may cause extraction to modify the permissions or modification time of a file outside the destination directory, or expose the contents of that file within the extracted tree.
In CPython 3.13 and earlier, the tarfile module's data and tar extraction filters are vulnerable to crafted archives containing a hard link to a symbolic link. Such archives may cause extraction to modify the permissions or modification time of a file outside the destination directory, or expose the contents of that file within the extracted tree.
-------- Forwarded Message -------- Date: Tue, 16 Jun 2026 16:01:03 +0100 From: Steve Dower <steve.dower () python org> Reply-To: security-sig () python org To: security-announce () python org
Reported by Jake Yamaki, Senior Consultant, Bishop Fox.
Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-12003 https://github.com/python/cpython/pull/151545 Security-announce mailing list -- security-announce () python org https://mail.python.org/mailman3//lists/security-announce.python.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.
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.
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.
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.
bz2.BZ2Decompressor objects could be reused after a decompression error. If an application caught the resulting OSError and retried with the same decompressor, crafted input could cause the decompressor to resume from an invalid internal state and perform out-of-bounds writes to a stack buffer. This could crash the process when processing untrusted data.
-------- Forwarded Message -------- Date: Wed, 3 Jun 2026 14:56:33 +0100 From: Stan Ulbrych via Security-announce <security-announce () python org> Reply-To: security-sig () python org To: security-announce () python org CC: Stan Ulbrych <stanulbrych () gmail com>
There is a MEDIUM severity vulnerability affecting CPython.
unicodedata.normalize() can take excessive CPU time when processing specially crafted Unicode input containing long runs of combining characters with alternating Canonical Combining Class values. This affects all normalization forms.
Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-3276 https://github.com/python/cpython/pull/149080
Security-announce mailing list -- security-announce () python org https://mail.python.org/mailman3//lists/security-announce.python.org
The ftpcp() function in Lib/ftplib.py was not updated when CVE-2021-4189 was fixed. While makepasv() was patched to replace server-supplied PASV host addresses with the actual peer address (getpeername()[0]), ftpcp() still calls parse227() directly and passes the raw attacker-controllable IP address and port to target.sendport(). This patch is related to CVE-2021-4189.
-------- Forwarded Message -------- Subject: [Security-announce][CVE-2026-7210] The expat and elementtree parsers use insufficient entropy for XML hash-flooding protection Date: Mon, 11 May 2026 17:58:49 +0100 From: Stan Ulbrych via Security-announce <security-announce () python org> Reply-To: security-sig () python org To: security-announce () python org CC: Stan Ulbrych <stanulbrych () gmail com>
There is a MEDIUM severity vulnerability affecting CPython.
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.
Fully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-7210 https://github.com/python/cpython/pull/149023
Best regards, Stan Ulbrych. Security-announce mailing list -- security-announce () python org To unsubscribe send an email to security-announce-leave () python org https://mail.python.org/mailman3//lists/security-announce.python.org
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.
-------- Forwarded Message -------- Date: Mon, 27 Apr 2026 20:48:33 +0000 From: Seth Larson <seth () python org> Reply-To: security-sig () python org To: security-announce () python org
There is a MEDIUM severity vulnerability affecting CPython. Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-3087 https://github.com/python/cpython/pull/146591
Security-announce mailing list -- security-announce () python org To unsubscribe send an email to security-announce-leave () python org https://mail.python.org/mailman3//lists/security-announce.python.org
Last updated 6 July 2026
Incomplete mitigation of CVE-2026-4519, %action expansion for command injection to webbrowser.open()
Last updated 6 July 2026
-------- Forwarded Message -------- Date: Fri, 10 Apr 2026 18:19:00 +0000 From: Seth Larson <seth () python org> Reply-To: security-sig () python org To: security-announce () python org
There is a MEDIUM severity vulnerability affecting {project}. Please see the linked CVE ID for the latest information on affected versions:
https://www.cve.org/CVERecord?id=CVE-2026-34460 https://github.com/python/cpython/pull/145267
Security-announce mailing list -- security-announce () python org To unsubscribe send an email to security-announce-leave () python org https://mail.python.org/mailman3//lists/security-announce.python.org
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.
CR/LF bytes were not rejected by HTTP client proxy tunnel headers or host.
Last updated 6 July 2026