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

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.

In Django 1.11.x before 1.11.18, 2.0.x before 2.0.10, and 2.1.x before 2.1.5, an Improper Neutralization of Special Elements in Output Used by a Downstream Component issue exists in django.views.defaults.pagenotfound(), leading to content spoofing (in a 404 error page) if a user fails to recognize that a crafted URL has malicious content.

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