Security releases issued: 1.8.3, 1.7.9, 1.4.21

In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.4.21, 1.7.9, and 1.8.3. These releases are now available on PyPI and our download page. These releases address several security issues detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.

Denial-of-service possibility by filling session store In previous versions of Django, the session backends created a new empty record in the session storage anytime request.session was accessed and there was a session key provided in the request cookies that didn't already have a session record. This could allow an attacker to easily create many new session records simply by sending repeated requests with unknown session keys, potentially filling up the session store or causing other users' session records to be evicted. The built-in session backends now create a session record only if the session is actually modified; empty session records are not created. Thus this potential DoS is now only possible if the site chooses to expose a session-modifying view to anonymous users. As each built-in session backend was fixed separately (rather than a fix in the core sessions framework), maintainers of third-party session backends should check whether the same vulnerability is present in their backend and correct it if so. Thanks Eric Peterson and Lin Hua Cheng for reporting the issue. This issue has been assigned the identifier CVE-2015-5143.

Header injection possibility since validators accept newlines in input Some of Django's built-in validators ( django.core.validators.EmailValidator , most seriously) didn't prohibit newline characters (due to the usage of $ instead of \Z in the regular expressions). If you use values with newlines in HTTP response or email headers, you can suffer from header injection attacks. Django itself isn't vulnerable because django.http.HttpResponse and the mail sending utilities in django.core.mail prohibit newlines in HTTP and SMTP headers, respectively. While the validators have been fixed in Django, if you're creating HTTP responses or email messages in other ways, it's a good idea to ensure that those methods prohibit newlines as well. You might also want to validate that any existing data in your application doesn't contain unexpected newlines. django.core.validators.validate_ipv4_address() , django.core.validators.validate_slug() , and django.core.validators.URLValidator are also affected, however, as of Django 1.6 the GenericIPAddresseField , IPAddressField , SlugField , and URLField form fields which use these validators all strip the input, so the possibility of newlines entering your data only exists if you are using these validators outside of the form fields. The undocumented, internally unused validate_integer() function is now stricter as it validates using a regular expression instead of simply casting the value using int() and checking if an exception was raised. Thanks Sjoerd Job Postmus for reporting the issue. This issue has been assigned the identifier CVE-2015-5144.

Denial-of-service possibility in URL validation django.core.validators.URLValidator included a regular expression that was extremely slow to evaluate against certain inputs. This regular expression has been simplified and optimized. Thanks João Silva and Ross Brunton for reporting the issue. This issue has been assigned the identifier CVE-2015-5145.

Affected supported versions Django master development branch

Django 1.8

Django 1.7 (except the URL DoS issue)

Django 1.4 (except the URL DoS issue) Per our supported versions policy, Django 1.5 and 1.6 are no longer receiving security updates.