An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. django.contrib.admin.utils.displayforfield() renders URLField values as clickable links in the admin without validating the URL. A value stored with an unsafe scheme is displayed as a link on changelist and read-only admin pages, which allows cross-site scripting against staff users who click the link. Exploitation requires the unsafe value to already be stored in the database. URLField validation through a ModelForm or the admin rejects unsafe schemes, so this affects applications that persist URLField data without running model validation, for example through direct queryset writes, deserialization, or bulk import of untrusted input. Django would like to thank Egor Saltykov for reporting this issue.
An issue was discovered in Django 5.2 before 5.2.2, 5.1 before 5.1.10, and 4.2 before 4.2.22. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.
An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.striptags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of striptags().
An issue was discovered in Django 5.1 before 5.1.8 and 5.0 before 5.0.14. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.views.LoginView, django.contrib.auth.views.LogoutView, and django.views.i18n.setlanguage are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.
An issue was discovered in Django v5.1.1, v5.0.9, and v4.2.16. The django.contrib.auth.forms.PasswordResetForm class, when used in a view implementing password reset flows, allows remote attackers to enumerate user e-mail addresses by sending password reset requests and observing the outcome (only when e-mail sending is consistently failing).
End of life: 4/2/2025, End of support: 8/7/2024, Latest version: 5.0.14
End of life: 4/2/2025, End of support: 8/7/2024, Latest version: 5.0.14
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.
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 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.
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.
https://docs.djangoproject.com/en/4.0/releases/security/ https://github.com/django/django/commit/5b6b257fa7ec37ff27965358800c67e2dd11c924 https://www.djangoproject.com/weblog/2022/oct/04/security-releases/ https://groups.google.com/forum/#!forum/django-announce
End of life: 12/1/2023, End of support: 4/5/2023, Latest version: 4.1.13
End of life: 12/1/2023, End of support: 4/5/2023, Latest version: 4.1.13
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 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.
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. The {% debug %} template tag did not properly encode the current context, posing a Cross-site scripting attack vector (XSS).
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.
: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.
End of life: 4/1/2023, End of support: 8/3/2022, Latest version: 4.0.10
End of life: 4/1/2023, End of support: 8/3/2022, Latest version: 4.0.10
HTTP requests for URLs with trailing newlines could bypass an upstream access control based on URL paths.
Running inventories of ~60k hosts no longer takes a very long time for events to show up Removed artifactdata from data sent to analytics as part of playbookonstats, since artifactdata can contain PII or sensitive data Regular users are no longer experiencing longer load times than a superuser when clicking to edit a job template Updated password validation support to allow modifying password complexity requirements using some Django configurations Fixed AWS inventory tags filtering to support the OR condition Updated Ansible version to 2.9.25 Updated Django version to 2.2.20 Fixed Tower's NGINX Instance vulnerability (CVE-2021-23017)
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.
: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+.
A flaw was found in django. Staff members could use the :mod:~django.contrib.admindocs TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by the developers to also expose the file contents, then not only the existence but also the file contents would have been exposed. The highest threat from this vulnerability is to data confidentiality.
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.
A flaw was found in django. MultiPartParser, UploadedFile, and FieldFile allowed directory-traversal via uploaded files with suitably crafted file names.