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.
Python 3.x through 3.9.1 has a buffer overflow in PyCArgrepr in ctypes/callproc.c, which may lead to remote code execution in certain Python applications that accept floating-point numbers as untrusted input.
Reference:
https://bugs.python.org/issue42938 https://github.com/python/cpython/pull/24239
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 ()
Fixed bug : buffer overflow in hashupdate() on long parameter. (CVE-2022-37454)
A vulnerability classified as problematic was found in Python 2.7.13. This vulnerability affects unknown code of the component pgAdmin4. The manipulation leads to uncontrolled search path. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
It was found that original patch for issues CVE-2015-1283 and CVE-2015-2716 used overflow checks that could be optimized out by some compilers applying certain optimization settings, which can cause the vulnerability to remain even after applying the patch.
One pattern in the fix for CVE-2015-1283/CVE-2015-2716 is:
/ bufferSize is positive here / do { bufferSize = 2; } while (bufferSize < neededSize && bufferSize > 0); if (bufferSize <= 0) { errorCode = XMLERRORNOMEMORY; return NULL;
Any of the modern optimizing compiler, IF able to infer that bufferSize is initially positive (which is true but not obvious to see through local reasoning), will eliminate bufferSize > 0 as always true when the execution is defined, and bufferSize <= 0 as always false when the execution is defined.
Without knowing that bufferSize starts positive, an optimizing compiler could also move the test bufferSize > 0 out of the loop, that is, compile the code as if it had been written:
if (bufferSize <= 0) errorCode = XMLERRORNOMEMORY; return NULL; else { do { bufferSize = 2; } while (bufferSize < neededSize); }
Both cases leads to not eliminating the vulnerability.
Upstream patch:
https://sourceforge.net/p/expat/codegit/ci/f0bec73b018caa07d3e75ec8dd967f3785d71bde/tree/expat/lib/xmlparse.c?diff=a238d7ea7a715ef3850c4cbdd86aeda7077b6bbc
An information disclosure flaw was found in the way Python CGI-savvy HTTP Server module processed HTTP GET requests with relative path in the URI (relevant CGI scripts were not executed, but rather their content displayed). A remote attacker could use this flaw to obtain sensitive information.
Upstream bug report: [1] http://bugs.python.org/issue2254
Related patch: [2] http://svn.python.org/view?view=revision&revision=71303
Last updated 24 July 2024
Last updated 24 July 2024
Description of problem:
When using SimpleXMLRPCServer from the standard library, if a client connection is closed before the complete request body has been received the server will enter an infinite loop consuming memory.
Version-Release number of selected component (if applicable):
python-2.6.6-29.el6.x8664
How reproducible:
always
Steps to Reproduce:
1. Start the server: >> import SimpleXMLRPCServer, SocketServer >> class Server(SocketServer.ThreadingMixIn, SimpleXMLRPCServer.SimpleXMLRPCServer): pass ... >> Server(('0.0.0.0', 12345)).serveforever()
2. Simulate a malicious or flakey client: $ echo -e 'POST /RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nlol bye' | nc localhost 12345 ^C
Actual results:
Server goes nuts, with a thread stuck in an infinite loop eating memory.
Expected results:
Bad request is discarded.
Additional info:
The bug is in /usr/lib64/python2.6/SimpleXMLRPCServer.py at line 453:
# Get arguments by reading body of request. # We read this in chunks to avoid straining # socket.read(); around the 10 or 15Mb mark, some platforms # begin to have problems (bug #792570). maxchunksize = 1010241024 sizeremaining = int(self.headers["content-length"]) L = [] while sizeremaining: chunksize = min(sizeremaining, maxchunksize) L.append(self.rfile.read(chunksize)) sizeremaining -= len(L[-1]) data = ''.join(L)
This code does not correctly handle EOF from self.rfile.read().
A security flaw was found in the way handlers for ftp:// and file:// URL schemes in the Python urllib and urllib2 extensible libraries processed the urllib open URL request. A remote attacker could use this flaw to access sensitive information or cause a denial of service (excessive CPU and memory use) of a Python web application, processing URLs, via a specially-crafted urllib open URL request.
It was reported [1] that distutils would create ~/.pypirc insecurely. There is a race from the time the user's username and password is written to the file to when it is chmod'd with appropriate permissions.
Typically, a user's home directory will be created with default 0700 permissions which would not allow for a local attacker to obtain access to this file during the race window, however if a user were to make their home directory 0755 they could be susceptible to this race.
One solution would be to use tempfile.mkstemp() to create the file and then move it in place.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650555
A flaw was reported [1] in Python's SimpleHTTPServer's listdirectory() function. Due to a missing charset parameter, if a user were to connect to SimpleHTTPServer using IE7, which engages in encoding-sniffing and can be tricked into interpretting the output as UTF7. Because of this, an attacker could hide <script> tags in UTF7-encoded characters which do not get quoted by cgi.encode(), allowing XSS attacks.
This has been corrected upstream in version 2.6.7rc2 [2], 2.5.6c1 [3]. It may be fixed in 2.7 as well, but I was unable to find a commit to match it against.
[1] http://bugs.python.org/issue11442 [2] http://svn.python.org/view/python/branches/release26-maint/Lib/SimpleHTTPServer.py?r1=66717&r2=88831&view=patch [3] http://svn.python.org/view/python/branches/release25-maint/Lib/SimpleHTTPServer.py?r1=53148&r2=88815&view=patch
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
A use-after-free exists in Python through 3.9 via heappushpop in heapq.
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.
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.
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 denial of service flaw was found in the way SSL module implementation of Python3, version 3 of the Python programming language (aka Python 3000), performed matching of the certificate's name in the case it contained many '' wildcard characters. A remote attacker, able to obtain valid certificate with its name containing a lot of '' wildcard characters could use this flaw to cause denial of service (excessive CPU consumption) by issuing request to validate such a certificate for / to an application using the Python's ssl.matchhostname() functionality.
Upstream bug report: [1] http://bugs.python.org/issue17980
CVE request: [2] http://www.openwall.com/lists/oss-security/2013/05/15/6 (is for python-backports-sslmatchhostname, but that code comes from Python 3.2 ssl module implementation) [3] http://www.openwall.com/lists/oss-security/2013/05/15/7
Acknowledgements:
Name: Florian Weimer (Red Hat Product Security)
Last updated 18 August 2025
DISPUTED An issue in Python cpython v.3.7 allows an attacker to obtain sensitive information via the asyncio.swapcurrenttask component. NOTE: this is disputed by the vendor because (1) neither 3.7 nor any other release is affected (it is a bug in some 3.12 pre-releases); (2) there are no common scenarios in which an adversary can call asyncio.swapcurrenttask but does not already have the ability to call arbitrary functions; and (3) there are no common scenarios in which sensitive information, which is not already accessible to an adversary, becomes accessible through this bug.
In Django 2.2 before 2.2.22, 3.1 before 3.1.10, and 3.2 before 3.2.2 (with Python 3.9.5+), URLValidator does not prohibit newlines and tabs (unless the URLField form field is used). If an application uses values with newlines in an HTTP response, header injection can occur. Django itself is unaffected because HttpResponse prohibits newlines in HTTP headers.
Python Software Foundation CPython version From 3.2 until 3.6.4 on Windows contains a Buffer Overflow vulnerability in os.symlink() function on Windows that can result in Arbitrary code execution, likely escalation of privilege. This attack appears to be exploitable via a python script that creates a symlink with an attacker controlled name or location. This vulnerability appears to have been fixed in 3.7.0 and 3.6.5.
Multiple integer overflows in Python 2.2.3 through 2.5.1, and 2.6, allow context-dependent attackers to have an unknown impact via a large integer value in the tabsize argument to the expandtabs method, as implemented by (1) the stringexpandtabs function in Objects/stringobject.c and (2) the unicodeexpandtabs function in Objects/unicodeobject.c. NOTE: this vulnerability reportedly exists because of an incomplete fix for CVE-2008-2315.
Multiple integer overflows in imageop.c in the imageop module in Python 1.5.2 through 2.5.1 allow context-dependent attackers to break out of the Python VM and execute arbitrary code via large integer values in certain arguments to the crop function, leading to a buffer overflow, a different vulnerability than CVE-2007-4965 and CVE-2008-1679.
Multiple integer overflows in the PyOSvsnprintf function in Python/mysnprintf.c in Python 2.5.2 and earlier allow context-dependent attackers to cause a denial of service (memory corruption) or have unspecified other impact via crafted input to string formatting operations. NOTE: the handling of certain integer values is also affected by related integer underflows and an off-by-one error.
Description of problem:
Added checks for integer overflows, contributed by Google. Some are only available if asserts are left in the code, in cases where they can't be triggered from Python code.
Proposed upstream patch:
http://svn.python.org/view?rev=60793&view=rev
Multiple buffer overflows in Python 2.5.2 and earlier on 32bit platforms allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a long string that leads to incorrect memory allocation during Unicode string processing, related to the unicoderesize function and the PyMemRESIZE macro.
Integer overflow in hashopenssl.c in the hashlib module in Python 2.5.2 and earlier might allow context-dependent attackers to defeat cryptographic digests, related to "partial hashlib hashing of data exceeding 4GB."