Safety CI > rucken/todo-django

pyup-update-urllib3-1.22-to-1.25.1

7 years ago

Update urllib3 from 1.22 to 1.25.1

Django 1.11, django-storages 1.6.5 and requests 2.18.4 have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

pyup-update-cx-oracle-6.1-to-7.1.3

7 years ago

7cbca409

Update cx-oracle from 6.1 to 7.1.3

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-virtualenv-15.1.0-to-16.5.0

7 years ago

d45de481

Update virtualenv from 15.1.0 to 16.5.0

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-urllib3-1.22-to-1.25

7 years ago

4047df3a

Update urllib3 from 1.22 to 1.25

Django 1.11, django-storages 1.6.5 and requests 2.18.4 have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

pyup-update-urllib3-1.22-to-1.24.2

7 years ago

35bdea23

Update urllib3 from 1.22 to 1.24.2

Django 1.11, django-storages 1.6.5 and requests 2.18.4 have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

pyup-update-deepdiff-3.3.0-to-4.0.6

7 years ago

d4bc6092

Update deepdiff from 3.3.0 to 4.0.6

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-pytz-2017.3-to-2019.1

7 years ago

7b5bdb7c

Update pytz from 2017.3 to 2019.1

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-deepdiff-3.3.0-to-4.0.5

7 years ago

66c23dbc

Update deepdiff from 3.3.0 to 4.0.5

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-jinja2-2.10-to-2.10.1

7 years ago

46edcc9d

Update jinja2 from 2.10 to 2.10.1

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-deepdiff-3.3.0-to-4.0.4

7 years ago

4bc1e411

Update deepdiff from 3.3.0 to 4.0.4

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-django-1.11-to-2.2

7 years, 1 month ago

10630614

Update django from 1.11 to 2.2

django-storages 1.6.5, requests 2.18.4 and urllib3 1.22 have known security vulnerabilities.

Package	Installed	Affected	Info
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-deepdiff-3.3.0-to-4.0.2

7 years, 1 month ago

dbdb5019

Update deepdiff from 3.3.0 to 4.0.2

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-deepdiff-3.3.0-to-4.0.1

7 years, 1 month ago

f9bc7f86

Update deepdiff from 3.3.0 to 4.0.1

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-deepdiff-3.3.0-to-4.0.0

7 years, 1 month ago

98616682

Update deepdiff from 3.3.0 to 4.0.0

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

pyup-update-django-cors-headers-2.1.0-to-2.5.2

7 years, 1 month ago

f3951549

Update django-cors-headers from 2.1.0 to 2.5.2

Django 1.11, django-storages 1.6.5 and 2 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=1.11a1,<1.11.28 , >=2.0a1,<2.2.10 , >=3.0a1,<3.0.3	show Django 1.11.28, 2.2.10 and 3.0.3 include a fix for CVE-2020-7471: SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.
Django	1.11	<2.1.9 , >=2.2a1,<2.2.2	show Django versions 2.1.9 and 2.2.2 include a patched bundled jQuery version to avoid a Prototype Pollution vulnerability.
Django	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	>=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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show Django 2.2.16, 3.0.10 and 3.1.1 include a fix for CVE-2020-24583: An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILE_UPLOAD_DIRECTORY_PERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command. #NOTE: This vulnerability affects only users of Python versions above 3.7. https://www.djangoproject.com/weblog/2020/sep/01/security-releases
Django	1.11	>=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	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11, and 2.2.4 include a fix for CVE-2019-14233: Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14234: Due to an error in shallow key transformation, key and index lookups for django.contrib.postgres.fields.JSONField, and key lookups for django.contrib.postgres.fields.HStoreField, were subject to SQL injection. This could, for example, be exploited via crafted use of "OR 1=1" in a key or index name to return all records, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to the QuerySet.filter() function.
Django	1.11	>=2.0a1,<2.1.11 , >=2.2a1,<2.2.4 , <1.11.23	show Django 1.11.23, 2.1.11 and 2.2.4 include a fix for CVE-2019-14232: If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	>=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	1.11	>=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	1.11	>=1.11a1,<1.11.22 , >=2.2a1,<2.2.3 , >=2.1a1,<2.1.10	show An issue was discovered in Django 1.11 before 1.11.22, 2.1 before 2.1.10, and 2.2 before 2.2.3. An HTTP request is not redirected to HTTPS when the SECURE_PROXY_SSL_HEADER and SECURE_SSL_REDIRECT settings are used, and the proxy connects to Django via HTTPS. In other words, django.http.HttpRequest.scheme has incorrect behavior when a client uses HTTP.
Django	1.11	<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	1.11	>=2.0a1,<2.0.11 , <1.11.19 , >=2.1a1,<2.1.6	show Django 1.11.19, 2.0.11 and 2.1.6 include a fix for CVE-2019-6975: Uncontrolled Memory Consumption via a malicious attacker-supplied value to the django.utils.numberformat.format() function.
Django	1.11	<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	1.11	>=1.11a1,<1.11.23 , >=2.0a1,<2.1.11 , >=2.2a1,<2.2.4	show Django 1.11.23, 2.1.11 and 2.2.4 includes a fix for CVE-2019-14235: If passed certain inputs, django.utils.encoding.uri_to_iri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.
Django	1.11	>=1.11a1,<1.11.15 , >=2.0a1,<2.0.8	show django.middleware.common.CommonMiddleware in Django 1.11.x before 1.11.15 and 2.0.x before 2.0.8 has an Open Redirect. A remote user can redirect the target user's browser to an arbitrary site.
Django	1.11	<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	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show Django 2.0.3, 1.8.19 and 1.11.11 include a fix for CVE-2018-7537: An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
Django	1.11	<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	1.11	<2.2.16 , >=3.0a1,<3.0.10 , >=3.1a1,<3.1.1	show An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.
Django	1.11	>=1.11a1,<1.11.21 , >=2.0a1,<2.1.9 , >=2.2a1,<2.2.2	show Django 1.11.21, 2.1.9 and 2.2.2 include a fix for CVE-2019-12308: The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, a non validated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.
Django	1.11	>=2.0a1,<2.0.3 , >=1.8a1,<1.8.19 , >=1.11a1,<1.11.11	show An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable. See: CVE-2018-7536.
Django	1.11	>=2.1a1,<2.1.1 , >=2.0a1,<2.0.9 , <1.11.16	show Django 1.11.16, 2.0.9 and 2.1.1 include a fix for a Race Condition vulnerability that could lead to data loss. https://github.com/django/django/commit/221ef69a9b89262456bb7abe0e5a4b2fda4a0695
Django	1.11	<1.10.8 , >=1.11a1,<1.11.5	show Django 1.10.8 and 1.11.5 include a fix for CVE-2017-12794: In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with "DEBUG = True" (which makes this page accessible) in your production settings. https://www.djangoproject.com/weblog/2017/sep/05/security-releases
Django	1.11	>=1.11a1,<1.11.29 , >=2.2a1,<2.2.11 , >=3.0a1,<3.0.4	show Django 1.11.29, 2.2.11 and 3.0.4 includes a fix for CVE-2020-9402: Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL. https://www.djangoproject.com/weblog/2020/mar/04/security-releases
Django	1.11	<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	1.11	>=1.11a1,<1.11.27 , >=2.0a1,<2.2.9 , >=3.0a1,<3.0.1	show Django 1.11.27, 2.2.9 and 3.0.1 include a fix for CVE-2019-19844: Account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. One mitigation in the new releases is to send password reset tokens only to the registered user email address.
Django	1.11	>=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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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	1.11	<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.
django-storages	1.6.5	<1.7	show Django-storages before 1.7 have an insecure default ACL of 'public-read' in the 'S3BotoStorage' and 'S3Boto3Storage' backends . https://github.com/jschneier/django-storages/commit/6ee6a739752923c60eaa1e82262c1d07208ec7f6
requests	2.18.4	>=2.3.0,<2.20.0	show Requests before 2.20.0 sends an HTTP Authorization header to an http URI upon receiving a same-hostname https-to-http redirect, which makes it easier for remote attackers to discover credentials by sniffing the network.
requests	2.18.4	<2.32.4	show Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.
requests	2.18.4	>=2.3.0,<2.31.0	show Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.
requests	2.18.4	<2.33.0	show Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.
requests	2.18.4	<2.32.2	show Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.
urllib3	1.22	>=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.22	>=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.22	<=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.22	<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.22	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.22	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.22	<1.23	show Urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the Authorization header to be exposed to unintended hosts or transmitted in cleartext.
urllib3	1.22	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.
urllib3	1.22	<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.22	<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.22	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800

older