Django security releases issued: 2.2.4, 2.1.11 and 1.11.23

In accordance with our security release policy, the Django team is issuing Django 1.11.23, Django 2.1.11, and Django 2.2.4. These releases addresses the security issues detailed below.

We encourage all users of Django to upgrade as soon as possible.

Thanks Guido Vranken and Sage M. Abdullah for reporting these issues.

CVE-2019-14232: Denial-of-service possibility in django.utils.text.Truncator

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
truncatechars_html and truncatewords_html template
filters, which were thus vulnerable.

The regular expressions used by Truncator have been simplified in order to
avoid potential backtracking issues. As a consequence, trailing punctuation may
now at times be included in the truncated output.

CVE-2019-14233: Denial-of-service possibility in strip_tags()

Due to the behavior of the underlying HTMLParser,
django.utils.html.strip_tags() would be extremely slow to evaluate
certain inputs containing large sequences of nested incomplete HTML entities.
The strip_tags() method is used to implement the corresponding
striptags template filter, which was thus also vulnerable.

strip_tags() now avoids recursive calls to HTMLParser when progress
removing tags, but necessarily incomplete HTML entities, stops being made.

Remember that absolutely NO guarantee is provided about the results of
strip_tags() being HTML safe. So NEVER mark safe the result of a
strip_tags() call without escaping it first, for example with

CVE-2019-14234: SQL injection possibility in key and index lookups for JSONField/HStoreField

Key and index lookups for
django.contrib.postgres.fields.JSONField and key lookups for 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().

CVE-2019-14235: Potential memory exhaustion in django.utils.encoding.uri_to_iri()

If passed certain inputs, django.utils.encoding.uri_to_iri could lead
to significant memory usage due to excessive recursion when re-percent-encoding
invalid UTF-8 octet sequences.

uri_to_iri() now avoids recursion when re-percent-encoding invalid UTF-8
octet sequences.

Affected supported versions

  • Django master development branch
  • Django 2.2 before version 2.2.4
  • Django 2.1 before version 2.1.11
  • Django 1.11 before version 1.11.23


Patches to resolve the issue have been applied to Django’s master branch and
the 2.2, 2.1, and 1.11 release branches. The patches may be obtained from the following changesets:

On the development master branch:

On the Django 2.2 release branch:

On the Django 2.1 release branch:

On the Django 1.11 release branch:

The following releases have been issued:

The PGP key ID used for this release is Carlton Gibson: E17DF5C82B4F9D00

General notes regarding security reporting

As always, we ask that potential security issues be reported via
private email to, and not via Django’s
Trac instance, Django’s GitHub repositories, or the django-developers list.
Please see our security policies
for further information.

Original Source

Leave a comment