An unspecified error with CJK codec tests call eval() on content retrieved throug HTTP in multibytecodecsupport.py in Python has an unknown impact and attack vector.
In Python 3.8.4, sys.path restrictions specified in a python38.pth file are ignored, allowing code to be loaded from arbitrary locations. The <executable-name>.pth file (e.g., the python.pth file) is not affected.
An XML External Entity (XXE) issue was discovered in Python through 3.9.1. The plistlib module no longer accepts entity declarations in XML plist files to avoid XML vulnerabilities.
In Python 3.6 through 3.6.10, 3.7 through 3.7.8, 3.8 through 3.8.4rc1, and 3.9 through 3.9.0b4 on Windows, a Trojan horse python3.dll might be used in cases where CPython is embedded in a native application. This occurs because python3X.dll may use an invalid search path for python3.dll loading (after PySetPath has been used). NOTE: this issue CANNOT occur when using python.exe from a standard (non-embedded) Python installation on Windows.
A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int("text"), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.frombytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability.
Last updated 18 August 2025
A use-after-free exists in Python through 3.9 via heappushpop in heapq.
A flaw was found in Python. The built-in modules httplib and http.client (included in Python 2 and Python 3, respectively) do not properly validate CRLF sequences in the HTTP request method, potentially allowing manipulation to the request by injecting additional HTTP headers. The highest threat from this vulnerability is to confidentiality and integrity.
A heap use after free vulnerability was reported in bzip2recover. A maliciously crafted file could cause the application to crash.
Proposed patch attached.
== ASAN output & backtrace == bzip2recover 1.0.6: extracts blocks from damaged .bz2 files. /opt/bzip-asan/bin/bzip2recover: searching for block boundaries ... block 1 runs from 176 to 175 block 2 runs from 224 to 871 block 3 runs from 920 to 919 block 4 runs from 968 to 1024 (incomplete) bzip2recover: splitting into blocks writing block 2 to crasherfile1' ... Program received signal SIGSEGV, Segmentation fault. ================================================================= ==8476== ERROR: AddressSanitizer: heap-use-after-free on address 0x60060000ef8c at pc 0x40277c bp 0x7fff7f1afe90 sp 0x7fff7f1afe80 READ of size 4 at 0x60060000ef8c thread T0 #0 0x40277b (/opt/bzip-asan/bin/bzip2recover+0x40277b) #1 0x401f35 (/opt/bzip-asan/bin/bzip2recover+0x401f35) #2 0x7f10fcae2af4 (/usr/lib64/libc-2.17.so+0x21af4) #3 0x4020e4 (/opt/bzip-asan/bin/bzip2recover+0x4020e4) 0x60060000ef8c is located 12 bytes inside of 24-byte region [0x60060000ef80,0x60060000ef98) freed by thread T0 here: #0 0x7f10fce98009 (/usr/lib64/libasan.so.0.0.0+0x16009) #1 0x40205c (/opt/bzip-asan/bin/bzip2recover+0x40205c) previously allocated by thread T0 here: #0 0x7f10fce98129 (/usr/lib64/libasan.so.0.0.0+0x16129) #1 0x40175f (/opt/bzip-asan/bin/bzip2recover+0x40175f) Shadow bytes around the buggy address: 0x0c013fff9da0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9db0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9dc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9dd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9de0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c013fff9df0: fd[fd]fd fa fa fa 00 00 00 fa fa fa fd fd fd fa 0x0c013fff9e00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c013fff9e40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap righ redzone: fb Freed Heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe
bt #0 0x00007ffff7a8fa11 in putc () from /lib64/libc.so.6 #1 0x00000000004046ad in bsPutBit (bit=0x0, bs=<optimized out>) at bzip2recover.c:183 #2 bsPutUChar (c=<optimized out>, bs=<optimized out>) at bzip2recover.c:246 #3 main (argc=<optimized out>, argv=<optimized out>) at bzip2recover.c:455 #4 0x00007ffff7a3caf5 in libcstartmain () from /lib64/libc.so.6 #5 0x0000000000405bd9 in start ()
Last updated 24 July 2024
An issue was discovered in comparedigest in Lib/hmac.py in Python through 3.9.1. Constant-time-defeating optimisations were possible in the accumulator variable in hmac.comparedigest.