July 8, 2015
Django 1.8.3 fixes several security issues and bugs in 1.8.2.
django.utils.deprecation.RemovedInDjango20Warning was renamed to
RemovedInDjango110Warning as the version roadmap was revised to 1.9, 1.10,
1.11 (LTS), 2.0 (drops Python 2 support). For backwards compatibility,
RemovedInDjango20Warning remains as an importable alias.
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
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.
Some of Django's built-in 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
HttpResponse and the mail sending
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
URLValidator are also affected, however, as
of Django 1.6 the
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.
URLValidator included a regular expression
that was extremely slow to evaluate against certain invalid inputs. This regular
expression has been simplified and optimized.
BaseRangeField.prepare_value()to use each
makemigrationsif a migrations module either is missing
__init__.pyor is a file (#24848).
QuerySet.exists()returning incorrect results after annotation with
RequestContextafter it's created (#24847).
not nullcolumn properties during field renaming of MySQL databases (#24817).
AutoFieldin PostgreSQL (#24892).
prefetch_related()after deleting objects (#24831).
choiceslonger than 1 day with
Caseexpressions. Annotating a query with multiple
Caseexpressions could unexpectedly filter out results (#24924).
SimpleTestCase.assertRaisesMessage()on Python 2.7.10 (#24903).
optparsemanagement commands by casting it to an integer (#24769).
prefetch_related()on databases other than PostgreSQL for models using UUID primary keys (#24912).
unique_togetherconstraints on MySQL (#24972).
ForeignKey.related_nameon Python 3 by fixing the false positive system check (#25016).
UUIDFieldprimary key and a child object that has an
AutoFieldprimary key (#24958).
unordered_listtemplate filter on certain inputs (#25031).
URLValidatorthat invalidated Punycode TLDs (#25059).