Out-of-memory when loading Plist
Excessive read buffering DoS in http.client
Last updated 6 July 2026
The incremental HTML parser (html.parser.HTMLParser) allows for CPU denial-of-service through repeated unterminated markup declarations when processing uncontrolled data.
If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.
Last updated 6 July 2026
Configuration Injection via Carriage Return (\r) in write() method
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.
Incomplete control character validation in http.cookies
If shutil.unpackarchive() is given a ZIP archive with an absolute Windows path containing a drive (C:\\...) then the archive will be extracted outside the target directory which is different than other operating systems. Only Windows is affected by this vulnerability.
tarfile: Skip DIRTYPE normalization during GNU LONGNAME/LONGLINK handling
Quadratic complexity in node ID cache clearing
When passing data to the b64decode(), standardb64decode(), and urlsafeb64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues.
This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafeb64decode() function, then your application does not use an alternative base64 alphabet.
The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64 alphabet they are expecting or verify that their application would not be affected if the b64decode() functions accepted "+" or "/" outside of altchars.