Update django to 5.1.5

[pyup-bot]

This PR updates Django from 5.1.3 to 5.1.5.

Changelog

5.1.5

==========================

*January 14, 2025*

Django 5.1.5 fixes a security issue with severity "moderate" and one bug in
5.1.4.

CVE-2024-56374: Potential denial-of-service vulnerability in IPv6 validation
============================================================================

Lack of upper bound limit enforcement in strings passed when performing IPv6
validation could lead to a potential denial-of-service attack. The undocumented
and private functions ``clean_ipv6_address`` and ``is_valid_ipv6_address`` were
vulnerable, as was the  :class:`django.forms.GenericIPAddressField` form field,
which has now been updated to define a ``max_length`` of 39 characters.

The :class:`django.db.models.GenericIPAddressField` model field was not
affected.

Bugfixes
========

* Fixed a crash when applying migrations with references to the removed
``Meta.index_together`` option (:ticket:`34856`).


==========================

5.1.4

==========================

*December 4, 2024*

Django 5.1.4 fixes one security issue with severity "high", one security issue
with severity "moderate", and several bugs in 5.1.3.

CVE-2024-53907: Denial-of-service possibility in ``strip_tags()``
=================================================================

:func:`~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
:tfilter:`striptags` template filter, which was thus also vulnerable.

``strip_tags()`` now has an upper limit of recursive calls to ``HTMLParser``
before raising a :exc:`.SuspiciousOperation` exception.

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
:func:`django.utils.html.escape`.

CVE-2024-53908: Potential SQL injection via ``HasKey(lhs, rhs)`` on Oracle
==========================================================================

Direct usage of the ``django.db.models.fields.json.HasKey`` lookup on Oracle
was subject to SQL injection if untrusted data was used as a ``lhs`` value.

Applications that use the :lookup:`has_key <jsonfield.has_key>` lookup through
the ``__`` syntax are unaffected.

Bugfixes
========

* Fixed a crash in ``createsuperuser`` on Python 3.13+ caused by an unhandled
``OSError`` when the username could not be determined (:ticket:`35942`).

* Fixed a regression in Django 5.1 where relational fields were not updated
when calling ``Model.refresh_from_db()`` on instances with deferred fields
(:ticket:`35950`).


==========================

Links

• PyPI: https://pypi.org/project/django
• Changelog: https://data.safetycli.com/changelogs/django/