An issue in the urllib.parse component of Python before 3.11.4 allows attackers to bypass blocklisting methods by supplying a URL that starts with blank characters.
A vulnerability was discovered in Python. A quadratic algorithm exists when processing inputs to the IDNA (RFC 3490) decoder, such that a crafted unreasonably long name being presented to the decoder could lead to a CPU denial of service. Hostnames are often supplied by remote servers that could be controlled by a malicious actor, which could trigger excessive CPU consumption on the client attempting to make use of an attacker-supplied hostname.
Fixed bug : buffer overflow in hashupdate() on long parameter. (CVE-2022-37454)
In Python before 3.10.3 on Windows, local users can gain privileges because the search path is inadequately secured. The installer may allow a local attacker to add user-writable directories to the system search path. To exploit, an administrator must have installed Python for all users and enabled PATH entries. A non-administrative user can trigger a repair that incorrectly adds user-writable paths into PATH, enabling search-path hijacking of other users and system services. This affects Python (CPython) through 3.7.12, 3.8.x through 3.8.12, 3.9.x through 3.9.10, and 3.10.x through 3.10.2.
A flaw was found in Python, specifically within the urllib.parse module. This module helps break Uniform Resource Locator (URL) strings into components. The issue involves how the urlparse method does not sanitize input and allows characters like '\r' and '\n' in the URL path. This flaw allows an attacker to input a crafted URL, leading to injection attacks.
DISPUTED Python 3.x through 3.10 has an open redirection vulnerability in lib/http/server.py due to no protection against multiple (/) at the beginning of URI path which may leads to information disclosure. NOTE: this is disputed by a third party because the http.server.html documentation page states "Warning: http.server is not recommended for production. It only implements basic security checks."
Python CPython could allow a remote attacker to bypass security restrictions, caused by a web cache poisoning flaw via urllib.parse.parseqsl and urllib.parse.parseqs. By sending a specially-crafted request parameter cloaking, an attacker could exploit this vulnerability to cause a difference in the interpretation of the request between the proxy and the server.
A flaw was found in Python, specifically in the FTP (File Transfer Protocol) client library in PASV (passive) mode. The issue is how the FTP client trusts the host from the PASV response by default. This flaw allows an attacker to set up a malicious FTP server that can trick FTP clients into connecting back to a given IP address and port. This vulnerability could lead to FTP client scanning ports, which otherwise would not have been possible.
Last updated 25 August 2025
A flaw was found in python. An improperly handled HTTP response in the HTTP client code of python may allow a remote attacker, who controls the HTTP server, to make the client script enter an infinite loop, consuming CPU time. The highest threat from this vulnerability is to system availability.
A flaw was found in Python 3's pydoc. This flaw allows a local or adjacent attacker who discovers or can convince another local or adjacent user to start a pydoc server to access the server and then use it to disclose sensitive information belonging to the other user that they would not normally have the ability to access. The highest threat from this vulnerability is to data confidentiality.
A flaw was found in python. A stack-based buffer overflow was discovered in the ctypes module provided within Python. Applications that use ctypes without carefully validating the input passed to it may be vulnerable to this flaw, which would allow an attacker to overflow a buffer on the stack and crash the application. The highest threat from this vulnerability is to system availability.
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.
BZ2decompress in decompress.c in bzip2 through 1.0.6 has an out-of-bounds write when there are many selectors.
AMD. A buffer overflow issue was addressed with improved memory handling.
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 ()
A command injection vulnerability was found in Python 2.x and 3.x, specifically within the mailcap module. Mailcap core-module is based on the format documented in RFC 1524. The “findmatch()” function does not sanitise the second argument (filename). As a result, the legitimate command (that is used for opening the specified mime type) is concatenated with an arbitrary command, injected by an attacker.
As reported on oss-security [1]:
So here are the CVE's for the two big ones, libxml2 and expat. Both are affected by the expansion of internal entities (which can be used to consume resources) and external entities (which can cause a denial of service against other services, be used to port scan, etc.).
To be clear:
==================== Internal entity expansion refers to the exponential/quadratic/fast linear expansion of XML entities, e.g.: ==================== <!DOCTYPE xmlbomb [ <!ENTITY a "1234567890" > <!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;"> <!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;"> <!ENTITY d "&c;&c;&c;&c;&c;&c;&c;&c;"> ]> <bomb>&d;</bomb>
or
<!DOCTYPE bomb [ <!ENTITY a "xxxxxxx... a couple of ten thousand chars"> ]> <bomb>&a;&a;&a;... repeat</bomb>
Which causes resources to be consumed
... Please use CVE-2013-0340 for expat internal entity expansion
[1] http://www.openwall.com/lists/oss-security/2013/02/22/4
A flaw was found in python-ipaddress. Improper input validation of octal strings in stdlib ipaddress allows unauthenticated remote attackers to perform indeterminate SSRF, RFI, and LFI attacks on many programs that rely on Python stdlib ipaddress. The highest threat from this vulnerability is to data integrity and system availability.
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.
Accessibility. A logging issue was addressed with improved data redaction.
An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as "not connected" and won't initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)
Last updated 24 July 2024
A flaw was found in the Python tarfile module. Extracting a crafted TAR archive with the tarfile.extract or tarfile.extractall functions could lead to a directory traversal vulnerability, resulting in overwrite of arbitrary files.
Last updated 19 September 2024
Last updated 7 May 2025
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.
Last updated 24 July 2024
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.