PatchFirst · Latest vulnerabilities
Vulnerabilities published for python-django in the last 30 days: 0. Listed in the KEV catalogue: 0.
Vulnerabilities: 32
In Django 1.11.x before 1.11.18, 2.0.x before 2.0.10, and 2.1.x before 2.1.5, an Improper Neutralization of Special Elements in Output Used by a Downstream Component issue exists in django.views.defaults.page_not_found(), leading to content spoofing (in a 404 error page) if a user fails to recognize that a crafted URL has malicious content.
An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. If django.utils.text.Truncator's chars() and words() methods were passed the html=True argument, they were extremely slow to evaluate certain inputs due to a catastrophic backtracking vulnerability in a regular expression. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus vulnerable.
An issue was discovered in Django 2.0 before 2.0.3, 1.11 before 1.11.11, and 1.8 before 1.8.19. The django.utils.html.urlize() function was extremely slow to evaluate certain inputs due to catastrophic backtracking vulnerabilities in two regular expressions (only one regular expression for Django 1.8.x). The urlize() function is used to implement the urlize and urlizetrunc template filters, which were thus vulnerable.
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.
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.
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.
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.
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.
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.
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://mysite.example.com\@attacker.com.
USN-2915-1 fixed vulnerabilities in Django. The upstream fix for CVE-2016-2512 introduced a regression for certain applications. This update fixes the problem by applying the complete upstream regression fix. Original advisory details: Mark Striemer discovered that Django incorrectly handled user-supplied redirect URLs containing basic authentication credentials. A remote attacker could possibly use this issue to perform a cross-site scripting attack or a malicious redirect. (CVE-2016-2512) Sjoerd Job Postmus discovered that Django incorrectly handled timing when doing password hashing operations. A remote attacker could possibly us
USN-2915-1 fixed vulnerabilities in Django. The upstream fix for CVE-2016-2512 introduced a regression for certain applications. This update fixes the problem by applying the complete upstream regression fix. Original advisory details: Mark Striemer discovered that Django incorrectly handled user-supplied redirect URLs containing basic authentication credentials. A remote attacker could possibly use this issue to perform a cross-site scripting attack or a malicious redirect. (CVE-2016-2512) Sjoerd Job Postmus discovered that Django incorrectly handled timing when doing password hashing operations. A remote attacker could possibly us
The get_format function in utils/formats.py in Django before 1.7.x before 1.7.11, 1.8.x before 1.8.7, and 1.9.x before 1.9rc2 might allow remote attackers to obtain sensitive application secrets via a settings key in place of a date/time format setting, as demonstrated by SECRET_KEY.
The (1) contrib.sessions.backends.base.SessionBase.flush and (2) cache_db.SessionStore.flush functions in Django 1.7.x before 1.7.10, 1.4.x before 1.4.22, and possibly other versions create empty sessions in certain circumstances, which allows remote attackers to cause a denial of service (session store consumption) via unspecified vectors.
contrib.sessions.middleware.SessionMiddleware in Django 1.8.x before 1.8.4, 1.7.x before 1.7.10, 1.4.x before 1.4.22, and possibly other versions allows remote attackers to cause a denial of service (session store consumption or session record removal) via a large number of requests to contrib.auth.views.logout, which triggers the creation of an empty session record.
Django before 1.4.21, 1.5.x through 1.6.x, 1.7.x before 1.7.9, and 1.8.x before 1.8.3 uses an incorrect regular expression, which allows remote attackers to inject arbitrary headers and conduct HTTP response splitting attacks via a newline character in an (1) email message to the EmailValidator, a (2) URL to the URLValidator, or unspecified vectors to the (3) validate_ipv4_address or (4) validate_slug validator.
The session backends in Django before 1.4.21, 1.5.x through 1.6.x, 1.7.x before 1.7.9, and 1.8.x before 1.8.3 allows remote attackers to cause a denial of service (session store consumption) via multiple requests with unique session keys.
The utils.http.is_safe_url function in Django before 1.4.20, 1.5.x, 1.6.x before 1.6.11, 1.7.x before 1.7.7, and 1.8.x before 1.8c1 does not properly validate URLs, which allows remote attackers to conduct cross-site scripting (XSS) attacks via a control character in a URL, as demonstrated by a \x08javascript: URL.
The utils.html.strip_tags function in Django 1.6.x before 1.6.11, 1.7.x before 1.7.7, and 1.8.x before 1.8c1, when using certain versions of Python, allows remote attackers to cause a denial of service (infinite loop) by increasing the length of the input string.
ModelMultipleChoiceField in Django 1.6.x before 1.6.10 and 1.7.x before 1.7.3, when show_hidden_initial is set to True, allows remote attackers to cause a denial of service by submitting duplicate values, which triggers a large number of SQL queries.
Check your installed stack and versions against the current vulnerability feeds.