-----BEGIN PGP SIGNED MESSAGE-----
AUSCERT Security Bulletin
Django: Multiple vulnerabilities
3 November 2016
AusCERT Security Bulletin Summary
Operating System: UNIX variants (UNIX, Linux, OSX)
Impact/Access: Unauthorised Access -- Remote/Unauthenticated
Cross-site Scripting -- Remote with User Interaction
CVE Names: CVE-2016-9013 CVE-2016-9014
Member content until: Saturday, December 3 2016
Multiple vulnerabilities have been identified in Django prior to
releases 1.8.16, 1.9.11 and 1.10.3. 
Django has provided the following details regarding the
"CVE-2016-9013: User with hardcoded password created when running
tests on Oracle
When running tests with an Oracle database, Django creates a
temporary database user. In older versions, if a password isn't
manually specified in the database settings TEST dictionary, a
hardcoded password is used. This could allow an attacker with
network access to the database server to connect.
This user is usually dropped after the test suite completes, but not
when using the manage.py test --keepdb option or if the user has an
active session (such as an attacker's connection).
A randomly generated password is now used for each test run.
Thanks Marti Raudsepp for reporting the issue."
"CVE-2016-9014: DNS rebinding vulnerability when DEBUG=True
Older versions of Django don't validate the Host header against
settings.ALLOWED_HOSTS when settings.DEBUG=True. This makes them
vulnerable to a DNS rebinding attack.
While Django doesn't ship a module that allows remote code
execution, this is at least a cross-site scripting vector, which
could be quite serious if developers load a copy of the production
database in development or connect to some production services for
which there's no development instance, for example. If a project
uses a package like the django-debug-toolbar, then the attacker
could execute arbitrary SQL, which could be especially bad if the
developers connect to the database with a superuser account.
settings.ALLOWED_HOSTS is now validated regardless of DEBUG. For
convenience, if ALLOWED_HOSTS is empty and DEBUG=True, the following
variations of localhost are allowed ['localhost', '127.0.0.1',
'::1']. If your local settings file has your production
ALLOWED_HOSTS value, you must now omit it to get those fallback
Thanks Aymeric Augustin for reporting the issue."
Django encourages all users to update to the latest release to fix
 Django security releases issued: 1.10.3, 1.9.11 and 1.8.16
AusCERT has made every effort to ensure that the information contained
in this document is accurate. However, the decision to use the information
described is the responsibility of each user or organisation. The decision to
follow or act on information or advice contained in this security bulletin is
the responsibility of each user or organisation, and should be considered in
accordance with your organisation's site policies and procedures. AusCERT
takes no responsibility for consequences which may arise from following or
acting on information or advice contained in this security bulletin.
Australian Computer Emergency Response Team
The University of Queensland
Internet Email: email@example.com
Facsimile: (07) 3365 7031
Telephone: (07) 3365 4417 (International: +61 7 3365 4417)
AusCERT personnel answer during Queensland business hours
which are GMT+10:00 (AEST).
On call after hours for member emergencies only.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----