Safety CI > ravellys/icsmp

pyup-update-boto3-1.16.14-to-1.20.49

4 years, 4 months ago

Update boto3 from 1.16.14 to 1.20.49

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-numpy-1.19.4-to-1.22.2

4 years, 4 months ago

3e81b3b8

Update numpy from 1.19.4 to 1.22.2

py 1.9.0, django 3.1.3, numpy 1.22.2 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-botocore-1.19.14-to-1.23.48

4 years, 4 months ago

d9223df4

Update botocore from 1.19.14 to 1.23.48

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-boto3-1.16.14-to-1.20.48

4 years, 4 months ago

7d4f7127

Update boto3 from 1.16.14 to 1.20.48

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-pillow-8.0.1-to-9.0.1

4 years, 4 months ago

1515934d

Update pillow from 8.0.1 to 9.0.1

py 1.9.0, django 3.1.3, numpy 1.19.4 and 6 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-s3transfer-0.3.3-to-0.5.1

4 years, 4 months ago

2861c8e6

Update s3transfer from 0.3.3 to 0.5.1

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-python-decouple-3.3-to-3.6

4 years, 4 months ago

1fea4793

Update python-decouple from 3.3 to 3.6

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-botocore-1.19.14-to-1.23.47

4 years, 4 months ago

b1ab63af

Update botocore from 1.19.14 to 1.23.47

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-boto3-1.16.14-to-1.20.47

4 years, 4 months ago

ce2c97ae

Update boto3 from 1.16.14 to 1.20.47

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-coverage-5.3-to-6.3.1

4 years, 4 months ago

0e1b996a

Update coverage from 5.3 to 6.3.1

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-django-3.1.3-to-4.0.2

4 years, 4 months ago

c280185b

Update django from 3.1.3 to 4.0.2

py 1.9.0, numpy 1.19.4, pillow 8.0.1 and 5 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-django-s3direct-1.1.8-to-2.0.0

4 years, 5 months ago

2b9704bd

Update django-s3direct from 1.1.8 to 2.0.0

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-botocore-1.19.14-to-1.23.46

4 years, 5 months ago

549b094c

Update botocore from 1.19.14 to 1.23.46

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-boto3-1.16.14-to-1.20.46

4 years, 5 months ago

cdbee1d4

Update boto3 from 1.16.14 to 1.20.46

py 1.9.0, django 3.1.3, numpy 1.19.4 and 7 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-41496: Buffer overflow in the array_from_pyobj function of fortranobject.c, which allows attackers to conduct a Denial of Service attacks by carefully constructing an array with negative values. NOTE: The vendor does not agree this is a vulnerability; the negative dimensions can only be created by an already privileged user (or internally). https://github.com/numpy/numpy/issues/19000
numpy	1.19.4	<1.21.0rc1	show Numpy 1.21.0rc1 includes a fix for CVE-2021-33430: A Buffer Overflow vulnerability in the PyArray_NewFromDescr_int function of ctors.c when specifying arrays of large dimensions (over 32) from Python code, which could let a malicious user cause a Denial of Service. NOTE: The vendor does not agree this is a vulnerability. In (very limited) circumstances a user may be able provoke the buffer overflow, the user is most likely already privileged to at least provoke denial of service by exhausting memory. Triggering this further requires the use of uncommon API (complicated structured dtypes), which is very unlikely to be available to an unprivileged user. https://github.com/numpy/numpy/issues/18939
numpy	1.19.4	<1.22.0	show Numpy 1.22.0 includes a fix for CVE-2021-34141: An incomplete string comparison in the numpy.core component in NumPy before 1.22.0 allows attackers to trigger slightly incorrect copying by constructing specific string objects. NOTE: the vendor states that this reported code behavior is "completely harmless." https://github.com/numpy/numpy/issues/18993
numpy	1.19.4	>=1.4.1,<1.22.2	show Numpy 1.22.2 includes a fix for CVE-2021-41495: Null Pointer Dereference vulnerability exists in numpy.sort in NumPy in the PyArray_DescrNew function due to missing return-value validation, which allows attackers to conduct DoS attacks by repetitively creating sort arrays. NOTE: While correct that validation is missing, an error can only occur due to an exhaustion of memory. If the user can exhaust memory, they are already privileged. Further, it should be practically impossible to construct an attack which can target the memory exhaustion to occur at exactly this place. NOTE2: The specs we include in this advisory differ from the publicly available on other sources. For example, the advisory posted by the NVD indicate that versions up to and including 1.19.0 are affected. However, research by Safety CLI Cybersecurity confirms that the vulnerability remained unaddressed until version 1.22.2.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

pyup-update-botocore-1.19.14-to-1.23.45

4 years, 5 months ago

626b8467

Update botocore from 1.19.14 to 1.23.45

py 1.9.0, django 3.1.3, pillow 8.0.1 and 6 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
py	1.9.0	<=1.11.0	show DISPUTED Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled. https://github.com/pytest-dev/py/issues/287
py	1.9.0	<=1.9.0	show Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
pillow	8.0.1	<12.2.0	show Affected versions of the pillow package are vulnerable to Integer Overflow due to unchecked accumulation of glyph advance values while tracking the current rendering position during font processing. When a font supplies an excessively large advance for each glyph, the running position counter wraps around because the arithmetic is performed in a fixed-width integer type that cannot represent the resulting magnitude. A remote attacker who can supply a crafted font file to a target that uses Pillow's font rendering can trigger the overflow, leading to incorrect memory calculations and potential memory corruption.
pillow	8.0.1	>=4.2.0,<12.2.0	show Affected versions of the pillow package are vulnerable to Denial of Service due to an unbounded loop when traversing PDF cross-reference trailer chains without cycle detection. The PdfParser module follows Prev pointers in PDF trailers to read cross-reference sections, but it does not track previously processed offsets, so a trailer whose Prev pointer references its own offset or forms a longer cycle causes the parser to loop indefinitely. A remote attacker who supplies a crafted PDF document can cause the parsing process to hang, consuming 100% CPU and rendering the consuming application unresponsive.
pillow	8.0.1	<10.0.0	show Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument. https://github.com/python-pillow/Pillow/pull/7244
pillow	8.0.1	>=4.3.0,<8.1.1	show Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICO container, and thus an attempted memory allocation can be very large.
pillow	8.0.1	<10.3.0	show Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25289: TiffDecode has a heap-based buffer overflow when decoding crafted YCbCr files because of certain interpretation conflicts with LibTIFF in RGBA mode. NOTE: this issue exists because of an incomplete fix for CVE-2020-35654. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28677: For EPS data, the readline implementation used in EPSImageFile has to deal with any combination of \r and \n as line endings. It used an accidentally quadratic method of accumulating lines while looking for a line ending. A malicious EPS file could use this to perform a DoS of Pillow in the open phase, before an image was accepted for opening. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28677-fix-eps-dos-on-open
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 includes a fix for SGI Decode buffer overrun. CVE-2020-35655 #5173.
pillow	8.0.1	<8.1.0	show Pillow 8.1.0 fixes TIFF OOB Write error. CVE-2020-35654 #5175.
pillow	8.0.1	<8.3.0	show Pillow 8.3.0 includes a fix for CVE-2021-34552: Pillow through 8.2.0 and PIL (also known as Python Imaging Library) through 1.1.7 allow an attacker to pass controlled parameters directly into a convert function to trigger a buffer overflow in Convert.c https://pillow.readthedocs.io/en/stable/releasenotes/8.3.0.html#buffer-overflow https://pillow.readthedocs.io/en/stable/releasenotes/index.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28676: For FLI data, FliDecode did not properly check that the block advance was non-zero, potentially leading to an infinite loop on load. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28676-fix-fli-dos
pillow	8.0.1	<9.0.1	show Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path. https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25288: There is an out-of-bounds read in J2kDecode, in j2ku_gray_i. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25292: The PDF parser allows a regular expression DoS (ReDoS) attack via a crafted PDF file because of a catastrophic backtracking regex. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.1	show Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS. https://github.com/python-pillow/Pillow/pull/5912 https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363
pillow	8.0.1	>=2.5.0,<10.0.1	show Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability. https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25293: There is an out-of-bounds read in SGIRleDecode.c. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.0	show In Pillow before 8.1.0, PcxDecode has a buffer over-read when decoding a crafted PCX file because the user-supplied stride value is trusted for buffer calculations.
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27921: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for a BLP container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	>=0,<8.2.0	show An issue was discovered in Pillow before 8.2.0. PSDImagePlugin.PsdImageFile lacked a sanity check on the number of input layers relative to the size of the data block. This could lead to a DoS on Image.open prior to Image.load.
pillow	8.0.1	<10.2.0	show Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code. https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html
pillow	8.0.1	>=5.2.0,<8.3.2	show Pillow from 5.2.0 and before 8.3.2 is vulnerable to Regular Expression Denial of Service (ReDoS) via the getrgb function. https://github.com/python-pillow/Pillow/commit/9e08eb8f78fdfd2f476e1b20b7cf38683754866b https://pillow.readthedocs.io/en/stable/releasenotes/8.3.2.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25291: In TiffDecode.c, there is an out-of-bounds read in TiffreadRGBATile via invalid tile boundaries. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-25290: In TiffDecode.c, there is a negative-offset memcpy with an invalid size. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
pillow	8.0.1	<9.0.0	show Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks. https://github.com/python-pillow/Pillow/pull/5921 https://github.com/advisories/GHSA-4fx9-vc88-q2xc
pillow	8.0.1	<10.2.0	show Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.
pillow	8.0.1	<9.2.0	show Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
pillow	8.0.1	<8.2.0	show Pillow 8.2.0 includes a fix for CVE-2021-25287: There is an out-of-bounds read in J2kDecode, in j2ku_graya_la. https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-25287-cve-2021-25288-fix-oob-read-in-jpeg2kdecode
pillow	8.0.1	<8.2.0	show Pillow version 8.2.0 includes a fix for CVE-2021-28678: For BLP data, BlpImagePlugin did not properly check that reads (after jumping to file offsets) returned data. This could lead to a DoS where the decoder could be run a large number of times on empty data. https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/MQHA5HAIBOYI3R6HDWCLAGFTIQP767FL/ https://github.com/python-pillow/Pillow/pull/5377 https://pillow.readthedocs.io/en/stable/releasenotes/8.2.0.html#cve-2021-28678-fix-blp-dos
pillow	8.0.1	<8.1.1	show Pillow 8.1.1 includes a fix for CVE-2021-27922: Pillow before 8.1.1 allows attackers to cause a denial of service (memory consumption) because the reported size of a contained image is not properly checked for an ICNS container, and thus an attempted memory allocation can be very large. https://pillow.readthedocs.io/en/stable/releasenotes/8.1.1.html
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.
django	3.1.3	<2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14	show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/
django	3.1.3	<3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6	show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.
django	3.1.3	>=1.10,<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.
django	3.1.3	<3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2	show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases
django	3.1.3	>=3.2a1,<3.2.4 , >=3.0a1,<3.1.12 , >=1.7,<2.2.24	show Affected versions of the Django package are vulnerable to Path Traversal due to improper validation of file paths in the django.contrib.admindocs module. The `TemplateDetailView` view allows staff members to verify the existence of arbitrary files by manipulating the file path. An attacker with staff privileges can exploit this vulnerability to check for the presence of files outside the template root directories, and if the `admindocs` templates are customized to display file contents, they can also access the contents of these files.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.
django	3.1.3	<4.2.21 , >=5.2a1,<5.2.1 , >=5.1.0a1,<5.1.9	show An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.
django	3.1.3	<2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1	show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
django	3.1.3	<3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3	show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).
django	3.1.3	<3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7	show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases
django	3.1.3	>=1.11a1,<4.2.15 , >=5.0a1,<5.0.8	show Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.
django	3.1.3	<3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5	show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.
django	3.1.3	<4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1	show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.
django	3.1.3	<4.2.28 , >=5.2a1,<5.2.11 , >=6.0a1,<6.0.2	show Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314
django	3.1.3	>=3.2a1,<3.2.1 , <2.2.21 , >=3.0a1,<3.1.9	show Django 2.2.21, 3.1.9 and 3.2.1 include a fix for CVE-2021-31542: MultiPartParser, UploadedFile, and FieldFile allowed directory traversal via uploaded files with suitably crafted file names. https://www.djangoproject.com/weblog/2021/may/04/security-releases
django	3.1.3	>=1.1.3,<3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2	show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.
django	3.1.3	<4.2.15 , >=5.0a1,<5.0.8	show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.
django	3.1.3	>=2.1a1,<3.2.15 , >=4.0a1,<4.0.7 , >=4.1a1,<4.2a1	show Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.
django	3.1.3	<4.2.24 , >=5.0a1,<5.1.12 , >=5.2a1,<5.2.6	show Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.
django	3.1.3	>=3.0a1,<3.0.13 , >=3.1a1,<3.1.7 , <2.2.19	show Django versions 2.2.19, 3.0.13 and 3.1.7 include a fix for CVE-2021-23336: Web cache poisoning via 'django.utils.http.limited_parse_qsl()'. Django contains a copy of 'urllib.parse.parse_qsl' which was added to backport some security fixes. A further security fix has been issued recently such that 'parse_qsl(' no longer allows using ';' as a query parameter separator by default.
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases
django	3.1.3	>=2.2a1,<2.2.20 , >=3.0a1,<3.0.14 , >=3.1a1,<3.1.8	show In Django 2.2 before 2.2.20, 3.0 before 3.0.14, and 3.1 before 3.1.8, MultiPartParser allowed directory traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability.
django	3.1.3	<4.2.26 , >=5.1a1,<5.1.14 , >=5.2a1,<5.2.8	show CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.
django	3.1.3	<3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7	show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.
django	3.1.3	<4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4	show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.
django	3.1.3	>=5.2,<5.2.2 , >=5.0a1,<5.1.10 , <4.2.22	show An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
django	3.1.3	>=2.0a1,<2.2.18 , >=3.0a1,<3.0.12 , >=3.1a1,<3.1.6	show Django 2.2.18, 3.0.12 and 3.1.6 include a fix for CVE-2021-3281: The django.utils.archive.extract method (used by "startapp --template" and "startproject --template") allows directory traversal via an archive with absolute paths or relative paths with dot segments.
django	3.1.3	>=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20	show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.
django	3.1.3	>=3.1a1,<3.1.10 , >=2.2a1,<2.2.22 , >=3.2a1,<3.2.2	show Django versions 3.2.2, 3.1.10 and 2.2.22 include a fix for CVE-2021-32052: 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. https://www.djangoproject.com/weblog/2021/may/06/security-releases
django	3.1.3	>=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24	show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases
django	3.1.3	<3.2.14 , >=4.0a1,<4.0.6	show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases
django	3.1.3	<2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2	show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.
django	3.1.3	<4.2.14 , >=5.0a1,<5.0.7	show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.
django	3.1.3	<3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1	show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases
django	3.1.3	<2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4	show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases
django	3.1.3	>=3.1a1,<3.1.13 , >=3.2a1,<3.2.5	show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce
django	3.1.3	<3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6	show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases
django	3.1.3	<4.2.27 , >=5.1,<5.1.15 , >=5.2,<5.2.9	show Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
sqlparse	0.4.1	<0.5.4	show Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.
sqlparse	0.4.1	<0.5.4	show Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts. Note: This issue is due to an incomplete fix for CVE-2024-4340.
sqlparse	0.4.1	<0.5.0	show Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.
sqlparse	0.4.1	>=0.4.0,<0.4.2	show Sqlparse version 0.4.2 includes a fix for CVE-2021-32839: In sqlparse versions 0.4.0 and 0.4.1 there is a Regular Expression Denial of Service vulnerability. The regular expression may cause exponential backtracking on strings containing many repetitions of "\r\n" in SQL comments. Only the formatting feature that removes comments from SQL statements is affected by this regular expression. As a workaround, avoid using the sqlformat.format function with keyword strip_comments=True or the --strip-comments command line flag when using the sqlformat command line tool. https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-p5w8-wqhj-9hhf https://github.com/andialbrecht/sqlparse/commit/8238a9e450ed1524e40cb3a8b0b3c00606903aeb
sqlparse	0.4.1	>=0.1.15,<0.4.4	show Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service). https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.25.11	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.25.11	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.25.11	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.25.11	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.25.11	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.25.11	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.25.11	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.25.11	>=1.25.4,<1.26.5	show Urllib3 1.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect. https://github.com/advisories/GHSA-q2q7-5pp4-w6pg
urllib3	1.25.11	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
django-debug-toolbar	3.1.1	<1.11.1 , >2,<2.2.1 , >3,<3.2.1	show A SQL Injection issue in the SQL Panel in Jazzband Django Debug Toolbar before 1.11.1, 2.x before 2.2.1, and 3.x before 3.2.1 allows attackers to execute SQL statements by changing the raw_sql input field of the SQL explain, analyze, or select form. See CVE-2021-30459.

older