Security releases and advisory issued

In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.7.6 and Django 1.8b2. These releases are now available on PyPI and our download page. These releases address a security issue in the Django admin. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated. If you are using a Django version older than 1.7, the security issue in the admin does not affect you, but there is an important advisory below regarding similar vulnerabilities that may exist in your own code.

Usually we prenotify certain key organizations when we make security releases, but unfortunately in this case a public disclosure of the vulnerability was made, forcing us to issue a release without the usual process.

Issue: XSS attack via properties in ModelAdmin.readonly_fields The ModelAdmin.readonly_fields attribute in the Django admin allows displaying model fields and model attributes. While the former were correctly escaped, the latter were not. Thus untrusted content could be injected into the admin, presenting an exploitation vector for XSS attacks. In this vulnerability, every model attribute used in readonly_fields that is not an actual model field (e.g. a @property) will fail to be escaped even if that attribute is not marked as safe. In this release, autoescaping is now correctly applied. This issue has been assigned the identifier CVE-2015-2241.

Advisory: HTML escaping when calling template filters from Python code The vulnerability described above was caused by the admin's use of the linebreaksbr function which doesn't escape its output by default when used outside of a template. This same behavior is present in other functions from django.template.defaultfilters that output HTML: join

linebreaksbr

linebreaks_filter

linenumbers

unordered_list

urlize

urlizetrunc In versions older than 1.8b2, they use autoescape=None as a default argument. This means when calling these functions directly from Python code, the input would be marked safe, but is not actually escaped, creating an XSS attack vector. We've remedied this issue in 1.8b2+ by changing the default value of this option to True . This ensures a safe behavior by default and helps prevent similar cases in the future. In addition, the documentation for writing custom template filters has been updated to recommend True as the default value. The change of the default parameter in 1.8 may create a compatibility issue for some users, but we feel it's important to use safe defaults. If escaping is not desired for your calls of these functions, you can revert to the old behavior by passing autoescape=False . Users of Django versions 1.0 to 1.7 should check their code for Python calls to these filters and ensure that any usage either explicitly sets autoescape=True or passes only trusted content. This issue only affects these template filters when they are called directly from Python code and not when they are used in templates.

Affected versions Django master development branch (currently at pre-alpha status)

Django 1.8 (currently at beta status)

Django 1.7