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.
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.
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.
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.
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.
In Django 3.2 before 3.2.21, 4.1 before 4.1.11, and 4.2 before 4.2.5, django.utils.encoding.uri_to_iri() is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.
In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.
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.
An issue was discovered in MultiPartParser in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2. Passing certain inputs to multipart forms could result in an infinite loop when parsing files.
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.
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.
An issue was discovered in Django 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.
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.
An issue was discovered in the Multipart Request Parser in Django 3.2 before 3.2.18, 4.0 before 4.0.10, and 4.1 before 4.1.7. Passing certain inputs (e.g., an excessive number of parts) to multipart forms could result in too many open files or memory exhaustion, and provided a potential vector for a denial-of-service attack.
In Django 3.2 before 3.2.22, 4.1 before 4.1.12, and 4.2 before 4.2.6, 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.
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.
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. This issue has low severity, according to the Django security policy.
In Django 3.2 before 3.2.20, 4 before 4.1.10, and 4.2 before 4.2.3, EmailValidator and URLValidator are subject to a potential ReDoS (regular expression denial of service) attack via a very large number of domain name labels of emails and URLs.
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. The Trunc() and Extract() database functions are subject to SQL injection if untrusted data is used as a kind/lookup_name value. Applications that constrain the lookup name and kind choice to a known safe list are unaffected.
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. 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.
An issue was discovered in Django 3.2 before 3.2.23, 4.1 before 4.1.13, and 4.2 before 4.2.7. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.forms.UsernameField is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.
This PR contains the following updates:
==3.2.4->==3.2.25GitHub Vulnerability Alerts
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.
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**optionsargument, and placing the injection payload in an option name.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(), andextra()methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed**kwargs.CVE-2022-41323
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.
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.
CVE-2023-41164
In Django 3.2 before 3.2.21, 4.1 before 4.1.11, and 4.2 before 4.2.5, django.utils.encoding.uri_to_iri() is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.
CVE-2024-27351
In Django 3.2 before 3.2.25, 4.2 before 4.2.11, and 5.0 before 5.0.3, the django.utils.text.Truncator.words() method (with html=True) and the truncatewords_html template filter are subject to a potential regular expression denial-of-service attack via a crafted string. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232 and CVE-2023-43665.
CVE-2022-22818
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.CVE-2022-23833
An issue was discovered in MultiPartParser in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2. Passing certain inputs to multipart forms could result in an infinite loop when parsing files.
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.
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.
CVE-2024-24680
An issue was discovered in Django 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.
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.
CVE-2023-24580
An issue was discovered in the Multipart Request Parser in Django 3.2 before 3.2.18, 4.0 before 4.0.10, and 4.1 before 4.1.7. Passing certain inputs (e.g., an excessive number of parts) to multipart forms could result in too many open files or memory exhaustion, and provided a potential vector for a denial-of-service attack.
CVE-2023-43665
In Django 3.2 before 3.2.22, 4.1 before 4.1.12, and 4.2 before 4.2.6, 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.
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.
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. This issue has low severity, according to the Django security policy.
CVE-2023-36053
In Django 3.2 before 3.2.20, 4 before 4.1.10, and 4.2 before 4.2.3,
EmailValidatorandURLValidatorare subject to a potential ReDoS (regular expression denial of service) attack via a very large number of domain name labels of emails and URLs.CVE-2022-34265
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. The
Trunc()andExtract()database functions are subject to SQL injection if untrusted data is used as a kind/lookup_name value. Applications that constrain the lookup name and kind choice to a known safe list are unaffected.CVE-2021-45115
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.
UserAttributeSimilarityValidatorincurred 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.CVE-2023-46695
An issue was discovered in Django 3.2 before 3.2.23, 4.1 before 4.1.13, and 4.2 before 4.2.7. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.forms.UsernameField is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.
Release Notes
django/django (django)
### [`v3.2.25`](https://redirect.github.com/django/django/compare/3.2.24...3.2.25) [Compare Source](https://redirect.github.com/django/django/compare/3.2.24...3.2.25) ### [`v3.2.24`](https://redirect.github.com/django/django/compare/3.2.23...3.2.24) [Compare Source](https://redirect.github.com/django/django/compare/3.2.23...3.2.24) ### [`v3.2.23`](https://redirect.github.com/django/django/compare/3.2.22...3.2.23) [Compare Source](https://redirect.github.com/django/django/compare/3.2.22...3.2.23) ### [`v3.2.22`](https://redirect.github.com/django/django/compare/3.2.21...3.2.22) [Compare Source](https://redirect.github.com/django/django/compare/3.2.21...3.2.22) ### [`v3.2.21`](https://redirect.github.com/django/django/compare/3.2.20...3.2.21) [Compare Source](https://redirect.github.com/django/django/compare/3.2.20...3.2.21) ### [`v3.2.20`](https://redirect.github.com/django/django/compare/3.2.19...3.2.20) [Compare Source](https://redirect.github.com/django/django/compare/3.2.19...3.2.20) ### [`v3.2.19`](https://redirect.github.com/django/django/compare/3.2.18...3.2.19) [Compare Source](https://redirect.github.com/django/django/compare/3.2.18...3.2.19) ### [`v3.2.18`](https://redirect.github.com/django/django/compare/3.2.17...3.2.18) [Compare Source](https://redirect.github.com/django/django/compare/3.2.17...3.2.18) ### [`v3.2.17`](https://redirect.github.com/django/django/compare/3.2.16...3.2.17) [Compare Source](https://redirect.github.com/django/django/compare/3.2.16...3.2.17) ### [`v3.2.16`](https://redirect.github.com/django/django/compare/3.2.15...3.2.16) [Compare Source](https://redirect.github.com/django/django/compare/3.2.15...3.2.16) ### [`v3.2.15`](https://redirect.github.com/django/django/compare/3.2.14...3.2.15) [Compare Source](https://redirect.github.com/django/django/compare/3.2.14...3.2.15) ### [`v3.2.14`](https://redirect.github.com/django/django/compare/3.2.13...3.2.14) [Compare Source](https://redirect.github.com/django/django/compare/3.2.13...3.2.14) ### [`v3.2.13`](https://redirect.github.com/django/django/compare/3.2.12...3.2.13) [Compare Source](https://redirect.github.com/django/django/compare/3.2.12...3.2.13) ### [`v3.2.12`](https://redirect.github.com/django/django/compare/3.2.11...3.2.12) [Compare Source](https://redirect.github.com/django/django/compare/3.2.11...3.2.12) ### [`v3.2.11`](https://redirect.github.com/django/django/compare/3.2.10...3.2.11) [Compare Source](https://redirect.github.com/django/django/compare/3.2.10...3.2.11) ### [`v3.2.10`](https://redirect.github.com/django/django/compare/3.2.9...3.2.10) [Compare Source](https://redirect.github.com/django/django/compare/3.2.9...3.2.10) ### [`v3.2.9`](https://redirect.github.com/django/django/compare/3.2.8...3.2.9) [Compare Source](https://redirect.github.com/django/django/compare/3.2.8...3.2.9) ### [`v3.2.8`](https://redirect.github.com/django/django/compare/3.2.7...3.2.8) [Compare Source](https://redirect.github.com/django/django/compare/3.2.7...3.2.8) ### [`v3.2.7`](https://redirect.github.com/django/django/compare/3.2.6...3.2.7) [Compare Source](https://redirect.github.com/django/django/compare/3.2.6...3.2.7) ### [`v3.2.6`](https://redirect.github.com/django/django/compare/3.2.5...3.2.6) [Compare Source](https://redirect.github.com/django/django/compare/3.2.5...3.2.6) ### [`v3.2.5`](https://redirect.github.com/django/django/compare/3.2.4...3.2.5) [Compare Source](https://redirect.github.com/django/django/compare/3.2.4...3.2.5)Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.
Thanks for the PR!
Deployments, as required, will be available below:
Please create PRs in draft mode. Mark as ready to enable:
After merge, new images are deployed in: