VendorsDjango Projectdjango1.8.11
Vulnerabilities

Django Project Django 1.8.11

Ranked by severity, then by exploit likelihood. Click a CVE ID for its full record.

4CVEs
CVE-2016-9013
Django 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3 use a hardcoded password for a temporary database user created when running tests with an Oracle database, which makes it easier for remote attackers to obtain access to the database server by leveraging failure to manually specify a password in the database settings TEST dictionary.
Published 2016-12-09 · Modified
9.8EPSS 0.052
CVE-2016-9014
Django before 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3, when settings.DEBUG is True, allow remote attackers to conduct DNS rebinding attacks by leveraging failure to validate the HTTP Host header against settings.ALLOWED_HOSTS.
Published 2016-12-09 · Modified
8.1EPSS 0.061
CVE-2017-7233
Django 1.10 before 1.10.7, 1.9 before 1.9.13, and 1.8 before 1.8.18 relies on user input in some cases to redirect the user to an "on success" URL. The security check for these redirects (namely ``django.utils.http.is_safe_url()``) considered some numeric URLs "safe" when they shouldn't be, aka an open redirect vulnerability. Also, if a developer relies on ``is_safe_url()`` to provide safe redirect targets and puts such a URL into a link, they could suffer from an XSS attack.
Published 2017-04-04 · Modified
6.1EPSS 0.024
CVE-2017-7234
A maliciously crafted URL to a Django (1.10 before 1.10.7, 1.9 before 1.9.13, and 1.8 before 1.8.18) site using the ``django.views.static.serve()`` view could redirect to any other domain, aka an open redirect vulnerability.
Published 2017-04-04 · Modified
6.1EPSS 0.018