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.
A flaw was found in Django. The Trunc() and Extract() database functions are subject to SQL injection if untrusted data is used as a kind/lookupname value.
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.orderby SQL injection if orderby is untrusted input from a client of a web application.
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 memory exhaustion flaw was found in the python-django package. This issue occurs when passing certain inputs, leading to a system crash and denial of service.
HTTP requests for URLs with trailing newlines could bypass an upstream access control based on URL paths.
A flaw was found in Django. The issue occurs when passing certain inputs to multipart forms, resulting in an infinite loop when parsing files.
A flaw was found in django. MultiPartParser, UploadedFile, and FieldFile allowed directory-traversal via uploaded files with suitably crafted file names.
:class:~django.core.validators.URLValidator, :func:~django.core.validators.validateipv4address, and :func:~django.core.validators.validateipv46address didn't prohibit leading zeros in octal literals. If you used such values you could suffer from indeterminate SSRF, RFI, and LFI attacks.
:func:~django.core.validators.validateipv4address and :func:~django.core.validators.validateipv46address validators were not affected on Python 3.9.5+.
:class:.UserAttributeSimilarityValidator incurred significant overhead evaluating submitted password that were artificially large in relative to the comparison values. On the assumption that access to user registration was unrestricted this provided a potential vector for a denial-of-service attack.
References:
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/
An information-disclosure flaw was found in Django, where the dictsort filter in Django's Template Language did not correctly validate user input. A network attacker could exploit this flaw using a suitably crafted key to force information disclosure or unintended method calls.
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.
A flaw was found in Django. The {% debug %} template tag did not properly encode the current context, posing a Cross-site scripting attack vector (XSS).
In Django 2.2 before 2.2.22, 3.1 before 3.1.10, and 3.2 before 3.2.2 (with Python 3.9.5+), URLValidator does not prohibit newlines and tabs (unless the URLField form field is used). If an application uses values with newlines in an HTTP response, header injection can occur. Django itself is unaffected because HttpResponse prohibits newlines in HTTP headers.
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.
End of life: 4/1/2024, End of support: 12/7/2021, Latest version: 3.2.25
End of life: 4/1/2024, End of support: 12/7/2021, Latest version: 3.2.25