pyup-update-coverage-5.5-to-7.6.9
3 months, 3 weeks ago
Update coverage from 5.5 to 7.6.9
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-sentry-sdk-1.1.0-to-2.19.2
3 months, 3 weeks ago
Update sentry-sdk from 1.1.0 to 2.19.2
Django 3.2.2 and gunicorn 20.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
pyup-update-sentry-sdk-1.1.0-to-2.19.1
3 months, 3 weeks ago
Update sentry-sdk from 1.1.0 to 2.19.1
Django 3.2.2 and gunicorn 20.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
pyup-update-django-3.2.2-to-5.1.4
3 months, 3 weeks ago
Update django from 3.2.2 to 5.1.4
gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-coverage-5.5-to-7.6.8
4 months, 1 week ago
Update coverage from 5.5 to 7.6.8
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-sentry-sdk-1.1.0-to-2.19.0
4 months, 1 week ago
Update sentry-sdk from 1.1.0 to 2.19.0
Django 3.2.2 and gunicorn 20.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
pyup-update-coverage-5.5-to-7.6.7
4 months, 2 weeks ago
Update coverage from 5.5 to 7.6.7
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-coverage-5.5-to-7.6.5
4 months, 2 weeks ago
Update coverage from 5.5 to 7.6.5
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-django-3.2.2-to-5.1.3
4 months, 3 weeks ago
Update django from 3.2.2 to 5.1.3
gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-sentry-sdk-1.1.0-to-2.18.0
4 months, 4 weeks ago
Update sentry-sdk from 1.1.0 to 2.18.0
Django 3.2.2 and gunicorn 20.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
pyup-update-dj-database-url-0.5.0-to-2.3.0
5 months, 1 week ago
Update dj-database-url from 0.5.0 to 2.3.0
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-coverage-5.5-to-7.6.4
5 months, 1 week ago
Update coverage from 5.5 to 7.6.4
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-sentry-sdk-1.1.0-to-2.17.0
5 months, 2 weeks ago
Update sentry-sdk from 1.1.0 to 2.17.0
Django 3.2.2 and gunicorn 20.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
pyup-update-psycopg2-binary-2.8.6-to-2.9.10
5 months, 2 weeks ago
Update psycopg2-binary from 2.8.6 to 2.9.10
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
pyup-update-psycopg2-2.8.6-to-2.9.10
5 months, 2 weeks ago
Update psycopg2 from 2.8.6 to 2.9.10
Django 3.2.2, gunicorn 20.1.0 and sentry-sdk 1.1.0 have known security vulnerabilities.
| Package | Installed | Affected | Info |
|---|---|---|---|
| Django | 3.2.2 | <3.2.24 , >=4.0a1,<4.2.10 , >=5.0a1,<5.0.2 |
show Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters. |
| Django | 3.2.2 | >=4.0a1,<4.1.10 , >=4.2a1,<4.2.3 , <3.2.20 |
show Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access. |
| Django | 3.2.2 | <3.2.16 , >=4.0a1,<4.0.8 , >=4.1a1,<4.1.2 |
show In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application. |
| Django | 3.2.2 | <2.2.25 , >=3.2a1,<3.2.10 , >=3.1a1,<3.1.14 |
show Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths. https://www.djangoproject.com/weblog/2021/dec/07/security-releases/ |
| Django | 3.2.2 | <4.2.18 , >=5.0.0,<5.0.11 , >=5.1.0,<5.1.5 |
show Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly. |
| Django | 3.2.2 | <3.2.19 , >=4.0a1,<4.1.9 , >=4.2a1,<4.2.1 |
show Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise. https://www.djangoproject.com/weblog/2023/may/03/security-releases |
| Django | 3.2.2 | <3.2.15 , >=4.0a1,<4.0.7 |
show Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input. https://www.djangoproject.com/weblog/2022/aug/03/security-releases |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories. |
| Django | 3.2.2 | <4.2.17 , >=5.0a1,<5.0.10 , >=5.1a1,<5.1.4 |
show Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities. |
| Django | 3.2.2 | <2.2.24 , >=3.0a1,<3.1.12 , >=3.2a1,<3.2.4 |
show Django before 2.2.24, 3.x before 3.1.12, and 3.2.x before 3.2.4 has a potential directory traversal via django.contrib.admindocs. Staff members could use the TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by application developers to also show file contents, then not only the existence but also the file contents would have been exposed. In other words, there is directory traversal outside of the template root directories. https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | <3.2.14 , >=4.0a1,<4.0.6 |
show Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments. https://www.djangoproject.com/weblog/2022/jul/04/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads. https://www.djangoproject.com/weblog/2022/feb/01/security-releases |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <3.2.25 , >=4.0a1,<4.2.11 , >=5.0a1,<5.0.3 |
show Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665). |
| Django | 3.2.2 | <2.2.28 , >=3.0a1,<3.2.13 , >=4.0a1,<4.0.4 |
show Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs. https://www.djangoproject.com/weblog/2022/apr/11/security-releases |
| Django | 3.2.2 | <3.2.17 , >=4.0a1,<4.0.9 , >=4.1a1,<4.1.6 |
show Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large. https://www.djangoproject.com/weblog/2023/feb/01/security-releases |
| Django | 3.2.2 | <2.2.27 , >=3.0a1,<3.2.12 , >=4.0a1,<4.0.2 |
show The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS. |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack. https://www.djangoproject.com/weblog/2022/jan/04/security-releases/ |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is. |
| Django | 3.2.2 | <4.2.20 , >=5.0a1,<5.0.13 , >=5.1a1,<5.0.7 |
show Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. |
| Django | 3.2.2 | <3.2.23 , >=4.0a1,<4.1.13 , >=4.2a1,<4.2.7 |
show Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows. https://www.djangoproject.com/weblog/2023/nov/01/security-releases |
| Django | 3.2.2 | <4.2.15 , >=5.0a1,<5.0.8 |
show Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters. |
| Django | 3.2.2 | <4.2.14 , >=5.0a1,<5.0.7 |
show Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption. |
| Django | 3.2.2 | <4.2.16 , >=5.0a1,<5.0.9 , >=5.1a1,<5.1.1 |
show A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses. |
| Django | 3.2.2 | <3.2.21 , >=4.0a1,<4.1.11 , >=4.2a1,<4.2.5 |
show Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri(). |
| Django | 3.2.2 | <3.2.18 , >=4.0a1,<4.0.10 , >=4.1a1,<4.1.7 |
show Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads. https://www.djangoproject.com/weblog/2023/feb/14/security-releases |
| Django | 3.2.2 | <2.2.26 , >=3.0a1,<3.2.11 , >=4.0a1,<4.0.1 |
show Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key. https://www.djangoproject.com/weblog/2022/jan/04/security-releases |
| Django | 3.2.2 | <3.2.22 , >=4.0a1,<4.1.12 , >=4.2a1,<4.2.6 |
show Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232. |
| Django | 3.2.2 | >=3.0.0a1,<3.1.12 , >=3.2.0a1,<3.2.4 , <2.2.24 |
show Django 2.2.24, 3.1.12, and 3.2.4 include a fix for CVE-2021-33571: In Django 2.2 before 2.2.24, 3.x before 3.1.12, and 3.2 before 3.2.4, URLValidator, validate_ipv4_address, and validate_ipv46_address do not prohibit leading zero characters in octal literals. This may allow a bypass of access control that is based on IP addresses. (validate_ipv4_address and validate_ipv46_address are unaffected with Python 3.9.5+). https://www.djangoproject.com/weblog/2021/jun/02/security-releases |
| Django | 3.2.2 | >=3.1a1,<3.1.13 , >=3.2a1,<3.2.5 |
show Django versions 3.1.13 and 3.2.5 include a fix for CVE-2021-35042: Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. https://www.djangoproject.com/weblog/2021/jul/01/security-releases/ https://www.openwall.com/lists/oss-security/2021/07/02/2 https://docs.djangoproject.com/en/3.2/releases/security/ https://groups.google.com/forum/#%21forum/django-announce |
| Django | 3.2.2 | <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. |
| gunicorn | 20.1.0 | <23.0.0 |
show Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse. |
| gunicorn | 20.1.0 | <22.0.0 |
show Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure. |
| gunicorn | 20.1.0 | <21.2.0 |
show A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time. |
| sentry-sdk | 1.1.0 | <1.4.1 |
show Sentry-sdk 1.4.1 includes a fix for a Race Condition vulnerability. https://github.com/getsentry/sentry-python/pull/1203 |
| sentry-sdk | 1.1.0 | <2.8.0 |
show Affected versions of Sentry's Python SDK are vulnerable to unintentional exposure of environment variables to subprocesses despite the env={} setting. In Python's 'subprocess' calls, all environment variables are passed to subprocesses by default. However, if you specifically do not want them to be passed to subprocesses, you may use 'env' argument in 'subprocess' calls. Due to the bug in Sentry SDK, with the Stdlib integration enabled (which is enabled by default), this expectation is not fulfilled, and all environment variables are being passed to subprocesses instead.
As a workaround, and if passing environment variables to child processes poses a security risk for you, you can disable all default integrations. |
| sentry-sdk | 1.1.0 | <1.14.0 |
show Sentry-sdk 1.14.0 includes a fix for CVE-2023-28117: When using the Django integration of versions prior to 1.14.0 of the Sentry SDK in a specific configuration it is possible to leak sensitive cookies values, including the session cookie to Sentry. These sensitive cookies could then be used by someone with access to your Sentry issues to impersonate or escalate their privileges within your application. In order for these sensitive values to be leaked, the Sentry SDK configuration must have 'sendDefaultPII' set to 'True'; one must use a custom name for either 'SESSION_COOKIE_NAME' or 'CSRF_COOKIE_NAME' in one's Django settings; and one must not be configured in one's organization or project settings to use Sentry's data scrubbing features to account for the custom cookie names. As of version 1.14.0, the Django integration of the 'sentry-sdk' will detect the custom cookie names based on one's Django settings and will remove the values from the payload before sending the data to Sentry. As a workaround, use the SDK's filtering mechanism to remove the cookies from the payload that is sent to Sentry. For error events, this can be done with the 'before_send' callback method and for performance related events (transactions) one can use the 'before_send_transaction' callback method. Those who want to handle filtering of these values on the server-side can also use Sentry's advanced data scrubbing feature to account for the custom cookie names. Look for the '$http.cookies', '$http.headers', '$request.cookies', or '$request.headers' fields to target with a scrubbing rule. https://github.com/getsentry/sentry-python/security/advisories/GHSA-29pr-6jr8-q5jm |
Python 3 badge
URL
https://pyup.io/repos/github/tiagocordeiro/djmenu/python-3-shield.svg
Markdown
[](https://pyup.io/repos/github/tiagocordeiro/djmenu/)
Restructured Text
.. image:: https://pyup.io/repos/github/tiagocordeiro/djmenu/python-3-shield.svg
:target: https://pyup.io/repos/github/tiagocordeiro/djmenu/
:alt: Python 3
HTML
<a href="https://pyup.io/repos/github/tiagocordeiro/djmenu/"><img src="https://pyup.io/repos/github/tiagocordeiro/djmenu/shield.svg" alt="Python 3" /></a>
Textile
!https://pyup.io/repos/github/tiagocordeiro/djmenu/python-3-shield.svg(Python 3)!:https://pyup.io/repos/github/tiagocordeiro/djmenu/
RDoc
{<img src="https://pyup.io/repos/github/tiagocordeiro/djmenu/python-3-shield.svg" alt="Python 3" />}[https://pyup.io/repos/github/tiagocordeiro/djmenu/]
pyup.io badge
URL
https://pyup.io/repos/github/tiagocordeiro/djmenu/shield.svg
Markdown
[](https://pyup.io/repos/github/tiagocordeiro/djmenu/)
Restructured Text
.. image:: https://pyup.io/repos/github/tiagocordeiro/djmenu/shield.svg
:target: https://pyup.io/repos/github/tiagocordeiro/djmenu/
:alt: Updates
HTML
<a href="https://pyup.io/repos/github/tiagocordeiro/djmenu/"><img src="https://pyup.io/repos/github/tiagocordeiro/djmenu/shield.svg" alt="Updates" /></a>
Textile
!https://pyup.io/repos/github/tiagocordeiro/djmenu/shield.svg(Updates)!:https://pyup.io/repos/github/tiagocordeiro/djmenu/
RDoc
{<img src="https://pyup.io/repos/github/tiagocordeiro/djmenu/shield.svg" alt="Updates" />}[https://pyup.io/repos/github/tiagocordeiro/djmenu/]