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

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.

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

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.

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.