MITRE’s CVE web site.
CWE is a registred trademark of the MITRE Corporation and the authoritative source of CWE content is
MITRE’s CWE web site.
OVAL is a registered trademark of The MITRE Corporation and the authoritative source of OVAL content is
MITRE’s OVAL web site.
Use of this information constitutes acceptance for use in an AS IS condition.
There are NO warranties, implied or otherwise, with regard to this information or its use.
Any use of this information is at the user’s risk.
It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content.
EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site.
ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT,
INDIRECT or any other kind of loss.
Powered by WPeMatico
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. (CVSS:5.8) (Last Update:2017-04-11)
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. (CVSS:5.8) (Last Update:2017-04-11)
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. (CVSS:7.5) (Last Update:2016-12-14)
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. (CVSS:6.8) (Last Update:2016-12-14)
The cookie parsing code in Django before 1.8.15 and 1.9.x before 1.9.10, when used on a site with Google Analytics, allows remote attackers to bypass an intended CSRF protection mechanism by setting arbitrary cookies. (CVSS:5.0) (Last Update:2016-10-04)
Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/js/admin/RelatedObjectLookups.js in Django before 1.8.14, 1.9.x before 1.9.8, and 1.10.x before 1.10rc1 allows remote attackers to inject arbitrary web script or HTML via vectors involving unsafe usage of Element.innerHTML. (CVSS:4.3) (Last Update:2016-08-05)
The password hasher in contrib/auth/hashers.py in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to enumerate users via a timing attack involving login requests. (CVSS:2.6) (Last Update:2016-06-15)
The utils.http.is_safe_url function in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks or possibly conduct cross-site scripting (XSS) attacks via a URL containing basic authentication, as demonstrated by http://email@example.com. (CVSS:4.3) (Last Update:2016-06-15)