:lookup:Key and index lookups <jsonfield.key> for :class:~django.contrib.postgres.fields.JSONField and :lookup:key lookups <hstorefield.key> for :class:~django.contrib.postgres.fields.HStoreField were subject to SQL injection, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed to QuerySet.filter().

Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. (One mitigation in the new releases is to send password reset tokens only to the registered user email address.)

Django 1.11 before 1.11.28, 2.2 before 2.2.10, and 3.0 before 3.0.3 allows SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.

QuerySet.explain() method was subject to SQL injection in option names, using a suitably crafted dictionary, with dictionary expansion, as the options argument.

This issue has High severity, according to the Django security policy [1].

QuerySet.annotate(), aggregate(), and extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed to these methods.

This issue has High severity, according to the Django security policy [1].

A flaw was found in Django in a way that GIS functions and aggregates on Oracle were subject to SQL injection, using a suitably crafted tolerance.

Reference: https://www.djangoproject.com/weblog/2020/mar/04/security-releases/

An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). The intermediate-level directories of the filesystem cache had the system's standard umask rather than 0o077.

An issue was discovered in Django 2.2 before 2.2.16, 3.0 before 3.0.10, and 3.1 before 3.1.1 (when Python 3.7+ is used). FILEUPLOADDIRECTORYPERMISSIONS mode was not applied to intermediate-level directories created in the process of uploading files. It was also not applied to intermediate-level collected static directories when using the collectstatic management command.

An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. Due to the behaviour of the underlying HTMLParser, django.utils.html.striptags would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities.

An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. If passed certain inputs, django.utils.encoding.uritoiri could lead to significant memory usage due to a recursion when repercent-encoding invalid UTF-8 octet sequences.

An issue was discovered in Django 1.11.x before 1.11.23, 2.1.x before 2.1.11, and 2.2.x before 2.2.4. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatecharshtml and truncatewordshtml template filters, which were thus vulnerable.

A flaw was found in Django. The issue occurs when passing certain inputs to multipart forms, resulting in an infinite loop when parsing files.

: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.

HTTP requests for URLs with trailing newlines could bypass an upstream access control based on URL paths.

An issue was discovered in Django 1.11 before 1.11.21, 2.1 before 2.1.9, and 2.2 before 2.2.2. The clickable Current URL value displayed by the AdminURLFieldWidget displays the provided value without validating it as a safe URL. Thus, an unvalidated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link.

An issue was discovered in Django 2.2 before 2.2.13 and 3.0 before 3.0.7. Query parameters generated by the Django admin ForeignKeyRawIdWidget were not properly URL encoded, leading to a possibility of an XSS attack.

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).

An issue was discovered in Django 2.2 before 2.2.13 and 3.0 before 3.0.7. In cases where a memcached backend does not perform key validation, passing malformed cache keys could result in a key collision, and potential data leakage.

Python CPython could allow a remote attacker to bypass security restrictions, caused by a web cache poisoning flaw via urllib.parse.parseqsl and urllib.parse.parseqs. By sending a specially-crafted request parameter cloaking, an attacker could exploit this vulnerability to cause a difference in the interpretation of the request between the proxy and the server.

'MultiPartParser' allowed directory-traversal via uploaded files with suitably crafted file names.

An HTTP detection flaw was discovered in Django. If deployed behind a reverse-proxy connecting to Django via HTTPS, django.http.HttpRequest.scheme() incorrectly detected client requests made using HTTP as using HTTPS. This resulted in incorrect results for issecure() and buildabsoluteuri(), and HTTP requests were not correctly redirected to HTTPS in accordance with SECURESSLREDIRECT.

A flaw was found in django where thedjango.utils.archive.extract() function, used by startapp --template and startproject --template, allowed directory-traversal via an archive with absolute paths or relative paths with dot segments.

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.