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.

Last updated 6 July 2026

The import hook in CPython that handles legacy .pyc files (SourcelessFileLoader) is incorrectly handled in FileLoader (a base class) and so does not use io.opencode() to read the .pyc files. sys.audit handlers for this audit event therefore do not fire.

CR/LF bytes were not rejected by HTTP client proxy tunnel headers or host.

Race condition in tempfile.TemporaryDirectory cleanup allows deleting files outside the temporary directory

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

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.

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.

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.

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.

A defect was discovered in the Python “ssl” module where there is a memory race condition with the ssl.SSLContext methods “certstorestats()” and “getcacerts()”. The race condition can be triggered if the methods are called at the same time as certificates are loaded into the SSLContext, such as during the TLS handshake with a certificate directory configured. This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.

A defect was discovered in the Python “ssl” module where there is a memory race condition with the ssl.SSLContext methods “certstorestats()” and “getcacerts()”. The race condition can be triggered if the methods are called at the same time as certificates are loaded into the SSLContext, such as during the TLS handshake with a certificate directory configured. This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.

A defect was discovered in the Python “ssl” module where there is a memory race condition with the ssl.SSLContext methods “certstorestats()” and “getcacerts()”. The race condition can be triggered if the methods are called at the same time as certificates are loaded into the SSLContext, such as during the TLS handshake with a certificate directory configured. This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.

A defect was discovered in the Python “ssl” module where there is a memory race condition with the ssl.SSLContext methods “certstorestats()” and “getcacerts()”. The race condition can be triggered if the methods are called at the same time as certificates are loaded into the SSLContext, such as during the TLS handshake with a certificate directory configured. This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.

An issue was found in CPython 3.12.0 subprocess module on POSIX platforms. The issue was fixed in CPython 3.12.1 and does not affect other stable releases.

When using the extragroups= parameter with an empty list as a value (ie extragroups=[]) the logic regressed to not call setgroups(0, NULL) before calling exec(), thus not dropping the original processes' groups before starting the new process. There is no issue when the parameter isn't used or when any value is used besides an empty list.

This issue only impacts CPython processes run with sufficient privilege to make the setgroups system call (typically root).

An issue was found in CPython 3.12.0 subprocess module on POSIX platforms. The issue was fixed in CPython 3.12.1 and does not affect other stable releases.

When using the extragroups= parameter with an empty list as a value (ie extragroups=[]) the logic regressed to not call setgroups(0, NULL) before calling exec(), thus not dropping the original processes' groups before starting the new process. There is no issue when the parameter isn't used or when any value is used besides an empty list.

This issue only impacts CPython processes run with sufficient privilege to make the setgroups system call (typically root).

An issue was found in CPython 3.12.0 subprocess module on POSIX platforms. The issue was fixed in CPython 3.12.1 and does not affect other stable releases.

When using the extragroups= parameter with an empty list as a value (ie extragroups=[]) the logic regressed to not call setgroups(0, NULL) before calling exec(), thus not dropping the original processes' groups before starting the new process. There is no issue when the parameter isn't used or when any value is used besides an empty list.

This issue only impacts CPython processes run with sufficient privilege to make the setgroups system call (typically root).

An issue was found in CPython 3.12.0 subprocess module on POSIX platforms. The issue was fixed in CPython 3.12.1 and does not affect other stable releases.

When using the extragroups= parameter with an empty list as a value (ie extragroups=[]) the logic regressed to not call setgroups(0, NULL) before calling exec(), thus not dropping the original processes' groups before starting the new process. There is no issue when the parameter isn't used or when any value is used besides an empty list.

This issue only impacts CPython processes run with sufficient privilege to make the setgroups system call (typically root).

An issue was found in CPython 3.12.0 subprocess module on POSIX platforms. The issue was fixed in CPython 3.12.1 and does not affect other stable releases.

When using the extragroups= parameter with an empty list as a value (ie extragroups=[]) the logic regressed to not call setgroups(0, NULL) before calling exec(), thus not dropping the original processes' groups before starting the new process. There is no issue when the parameter isn't used or when any value is used besides an empty list.

This issue only impacts CPython processes run with sufficient privilege to make the setgroups system call (typically root).

The import hook in CPython that handles legacy .pyc files (SourcelessFileLoader) is incorrectly handled in FileLoader (a base class) and so does not use io.opencode() to read the .pyc files. sys.audit handlers for this audit event therefore do not fire.

There is an issue in CPython when using bytes.decode("unicodeescape", error="ignore|replace"). If you are not using the "unicodeescape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.

There is an issue in CPython when using bytes.decode("unicodeescape", error="ignore|replace"). If you are not using the "unicodeescape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.

There is an issue in CPython when using bytes.decode("unicodeescape", error="ignore|replace"). If you are not using the "unicodeescape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.

There is an issue in CPython when using bytes.decode("unicodeescape", error="ignore|replace"). If you are not using the "unicodeescape" encoding or an error handler your usage is not affected. To work-around this issue you may stop using the error= handler and instead wrap the bytes.decode() call in a try-except catching the DecodeError.

CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.setnpnprotocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).

CPython 3.9 and earlier doesn't disallow configuring an empty list ("[]") for SSLContext.setnpnprotocols() which is an invalid value for the underlying OpenSSL API. This results in a buffer over-read when NPN is used (see CVE-2024-5535 for OpenSSL). This vulnerability is of low severity due to NPN being not widely used and specifying an empty list likely being uncommon in-practice (typically a protocol name would be configured).