An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed QuerySet.annotate() or QuerySet.alias().

Direct usage of the django.db.models.fields.json.HasKey lookup on Oracle is subject to SQL injection if untrusted data is used as a lhs value. Applications that use the lookup through the syntax are unaffected.

An issue was discovered in Django 4.2 before 4.2.24, 5.1 before 5.1.12, and 5.2 before 5.2.6. FilteredRelation is subject to SQL injection in column aliases, using a suitably crafted dictionary, with dictionary expansion, as the kwargs passed QuerySet.annotate() or QuerySet.alias().

getsupportedlanguagevariant() was subject to a potential denial-of-service attack when used with very long strings including a specific set of characters.

Affected versions =================

Django main development branch Django 5.1 Django 5.0 Django 4.2

Description: urlize, urlizetrunc, and AdminURLFieldWidget were subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.

Affected versions =================

Django main development branch Django 5.1 (currently at release candidate status) Django 5.0 Django 4.2

The wrap() and :tfilter:wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Affected versions =================

Django main development branch Django 5.2 (currently at beta status) Django 5.1 Django 5.0 Django 4.2

As of the 1.2 release, the core Django framework includes a system, enabled by default, for detecting and preventing cross-site request forgery (CSRF) attacks against Django-powered applications. Previous Django releases provided a different, optionally-enabled system for the same purpose.

The Django 1.2 CSRF protection system involves the generation of a random token, inserted as a hidden field in outgoing forms. The same value is also set in a cookie, and the cookie value and form value are compared on submission.

The provided template tag for inserting the CSRF token into forms -- {% csrftoken %} -- explicitly trusts the cookie value, and displays it as-is. Thus, an attacker who is able to tamper with the value of the CSRF cookie can cause arbitrary content to be inserted, unescaped, into the outgoing HTML of the form, enabling cross-site scripting (XSS) attacks.

This issue was first reported via a public ticket in Django's Trac instance; while being triaged it was then independently reported, with broader description, by Jeff Balogh of Mozilla.

http://www.djangoproject.com/weblog/2010/sep/08/security-release/

http://www.djangoproject.com/weblog/2011/feb/08/security/

Django includes a CSRF-protection mechanism, which makes use of a token inserted into outgoing forms. Middleware then checks for the token's presence on form submission, and validates it.

Previously, however, our CSRF protection made an exception for AJAX requests, on the following basis:

1. Many AJAX toolkits add an X-Requested-With header when using XMLHttpRequest. 2. Browsers have strict same-origin policies regarding XMLHttpRequest. 3. In the context of a browser, the only way that a custom header of this nature can be added is with XMLHttpRequest.

Therefore, for ease of use, we did not apply CSRF checks to requests that appeared to be AJAX on the basis of the X-Requested-With header. The Ruby on Rails web framework had a similar exemption.

Recently, engineers at Google made members of the Ruby on Rails development team aware of a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website. This can allow a forged request to appear to be an AJAX request, thereby defeating CSRF protection which trusts the same-origin nature of AJAX requests.

Michael Koziarski of the Rails team brought this to our attention, and we were able to produce a proof-of-concept demonstrating the same vulnerability in Django's CSRF handling.

To remedy this, Django will now apply full CSRF validation to all requests, regardless of apparent AJAX origin. This is technically backwards-incompatible, but the security risks have been judged to outweigh the compatibility concerns in this case.

Additionally, Django will now accept the CSRF token in the custom HTTP header X-CSRFTOKEN, as well as in the form submission itself, for ease of use with popular JavaScript toolkits which allow insertion of custom headers into all AJAX requests.

http://www.djangoproject.com/weblog/2011/feb/08/security/

Django's form system includes form fields and widgets for performing file uploads; in rendering these fields, the name of the file currently stored in the field is displayed. In the process of rendering, the filename is displayed without being escaped, as reported by Trac user "e.generalov".

In many cases this does not result in a cross-site-scripting vulnerability, as file-storage backends can and are encouraged to (and the default backends provided with Django do) sanitize the supplied filename according to their requirements. However, the risk of a vulnerability appearing in a backend which does not sanitize, or which performs insufficient sanitization, is such that Django will now automatically escape filenames in form rendering.

An issue was discovered in Django 5.2 before 5.2.15 and 6.0 before 6.0.6. django.middleware.cache.UpdateCacheMiddleware in Django does not add Authorization to the Vary response header for requests bearing that header without Cache-Control: public, which allows remote attackers to read private cached responses via unauthenticated requests to the same URL. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Shai Berger for reporting this issue.

An issue was discovered in Django 6.0 before 6.0.6 and 5.2 before 5.2.15. django.core.mail.backends.smtp.EmailBackend in Django fails to prevent reuse of a partially-initialized connection after a failed STARTTLS handshake when failsilently=True, which allows on-path network attackers to read email content via cleartext interception. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Kasper Dupont for reporting this issue.

End of life: 12/2/2019, End of support: 4/1/2019, Latest version: 2.1.15

End of life: 12/2/2019, End of support: 4/1/2019, Latest version: 2.1.15

End of life: 4/7/2026, End of support: 12/4/2023, Latest version: 4.2.30

End of life: 4/7/2026, End of support: 12/4/2023, Latest version: 4.2.30

End of life: 4/1/2023, End of support: 8/3/2022, Latest version: 4.0.10

End of life: 4/1/2023, End of support: 8/3/2022, Latest version: 4.0.10

End of life: 4/2/2025, End of support: 8/7/2024, Latest version: 5.0.14

End of life: 4/2/2025, End of support: 8/7/2024, Latest version: 5.0.14

End of life: 4/6/2021, End of support: 8/3/2020, Latest version: 3.0.14

End of life: 4/6/2021, End of support: 8/3/2020, Latest version: 3.0.14

End of life: 4/1/2020, End of support: 12/2/2017, Latest version: 1.11.29

End of life: 4/1/2020, End of support: 12/2/2017, Latest version: 1.11.29

End of life: 12/1/2023, End of support: 4/5/2023, Latest version: 4.1.13

End of life: 12/1/2023, End of support: 4/5/2023, Latest version: 4.1.13

End of life: 4/11/2022, End of support: 12/2/2019, Latest version: 2.2.28

End of life: 4/11/2022, End of support: 12/2/2019, Latest version: 2.2.28

End of life: 4/1/2019, End of support: 8/1/2018, Latest version: 2.0.13

End of life: 4/1/2019, End of support: 8/1/2018, Latest version: 2.0.13

End of life: 12/7/2021, End of support: 4/6/2021, Latest version: 3.1.14