Django

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

*July 1, 2020*

Django 2.2.14 fixes a bug in 2.2.13.

Bugfixes
========

* Fixed messages of ``InvalidCacheKey`` exceptions and ``CacheKeyWarning``
warnings raised by cache key validation (:ticket:`31654`).


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

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

*June 3, 2020*

Django 2.2.13 fixes two security issues and a regression in 2.2.12.

CVE-2020-13254: Potential data leakage via malformed memcached keys
===================================================================

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. In order to avoid this vulnerability, key validation is added to the
memcached cache backends.

CVE-2020-13596: Possible XSS via admin ``ForeignKeyRawIdWidget``
================================================================

Query parameters for the admin ``ForeignKeyRawIdWidget`` were not properly URL
encoded, posing an XSS attack vector. ``ForeignKeyRawIdWidget`` now
ensures query parameters are correctly URL encoded.

Bugfixes
========

* Fixed a regression in Django 2.2.12 that affected translation loading for
apps providing translations for territorial language variants as well as a
generic language, where the project has different plural equations for the
language (:ticket:`31570`).

* Tracking a jQuery security release, upgraded the version of jQuery used by
the admin from 3.3.1 to 3.5.1.


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

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

*April 1, 2020*

Django 2.2.12 fixes a bug in 2.2.11.

Bugfixes
========

* Added the ability to handle ``.po`` files containing different plural
equations for the same language (:ticket:`30439`).


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

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

*March 4, 2020*

Django 2.2.11 fixes a security issue and a data loss bug in 2.2.10.

CVE-2020-9402: Potential SQL injection via ``tolerance`` parameter in GIS functions and aggregates on Oracle
============================================================================================================

GIS functions and aggregates on Oracle were subject to SQL injection,
using a suitably crafted ``tolerance``.

Bugfixes
========

* Fixed a data loss possibility in the
:meth:`~django.db.models.query.QuerySet.select_for_update`. When using
related fields or parent link fields with :ref:`multi-table-inheritance` in
the ``of`` argument, the corresponding models were not locked
(:ticket:`31246`).


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

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

*February 3, 2020*

Django 2.2.10 fixes a security issue in 2.2.9.

CVE-2020-7471: Potential SQL injection via ``StringAgg(delimiter)``
===================================================================

:class:`~django.contrib.postgres.aggregates.StringAgg` aggregation function was
subject to SQL injection, using a suitably crafted ``delimiter``.


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

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

*December 18, 2019*

Django 2.2.9 fixes a security issue and a data loss bug in 2.2.8.

CVE-2019-19844: Potential account hijack via password reset form
================================================================

By submitting a suitably crafted email address making use of Unicode
characters, that compared equal to an existing user email when lower-cased for
comparison, an attacker could be sent a password reset token for the matched
account.

In order to avoid this vulnerability, password reset requests now compare the
submitted email using the stricter, recommended algorithm for case-insensitive
comparison of two identifiers from `Unicode Technical Report 36, section
2.11.2(B)(2)`__. Upon a match, the email containing the reset token will be
sent to the email address on record rather than the submitted address.

.. __: https://www.unicode.org/reports/tr36/#Recommendations_General

Bugfixes
========

* Fixed a data loss possibility in
:class:`~django.contrib.postgres.forms.SplitArrayField`. When using with
``ArrayField(BooleanField())``, all values after the first ``True`` value
were marked as checked instead of preserving passed values (:ticket:`31073`).


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