VuXML ID | Description |
cb116651-79db-4c09-93a2-c38f9df46724 | django -- multiple vulnerabilities
The Django project reports:
Today the Django team released Django 1.10.3, Django 1.9.11,
and 1.8.16. These releases addresses two security issues
detailed below. We encourage all users of Django to upgrade
as soon as possible.
- User with hardcoded password created when running tests on Oracle
- DNS rebinding vulnerability when DEBUG=True
Discovery 2016-11-01 Entry 2016-11-02 py27-django
py33-django
py34-django
py35-django
< 1.8.16
py27-django18
py33-django18
py34-django18
py35-django18
< 1.8.16
py27-django19
py33-django19
py34-django19
py35-django19
< 1.9.11
py27-django110
py33-django110
py34-django110
py35-django110
< 1.10.3
https://www.djangoproject.com/weblog/2016/nov/01/security-releases/
CVE-2016-9013
CVE-2016-9014
|
21c59f5e-7cc5-11e2-9c11-080027a5ec9a | django -- multiple vulnerabilities
The Django Project reports:
These security releases fix four issues: one potential phishing
vector, one denial-of-service vector, an information leakage issue,
and a range of XML vulnerabilities.
-
Host header poisoning
an attacker could cause Django to generate and display URLs that
link to arbitrary domains. This could be used as part of a phishing
attack. These releases fix this problem by introducing a new
setting, ALLOWED_HOSTS, which specifies a whitelist of domains your
site is known to respond to.
Important: by default Django 1.3.6 and 1.4.4 set ALLOWED_HOSTS to
allow all hosts. This means that to actually fix the security
vulnerability you should define this setting yourself immediately
after upgrading.
-
Formset denial-of-service
an attacker can abuse Django's tracking of the number of forms in
a formset to cause a denial-of-service attack. This has been fixed
by adding a default maximum number of forms of 1,000. You can still
manually specify a bigger max_num, if you wish, but 1,000 should be
enough for anyone.
-
XML attacks
Django's serialization framework was vulnerable to attacks via XML
entity expansion and external references; this is now fixed.
However, if you're parsing arbitrary XML in other parts of your
application, we recommend you look into the defusedxml Python
packages which remedy this anywhere you parse XML, not just via
Django's serialization framework.
-
Data leakage via admin history log
Django's admin interface could expose supposedly-hidden
information via its history log. This has been fixed.
Discovery 2013-02-21 Entry 2013-02-24 py26-django
py27-django
ge 1.3 lt 1.3.6
ge 1.4 lt 1.4.4
CVE-2013-1664
CVE-2013-1665
CVE-2013-0305
CVE-2013-0306
58022
58061
|
11c52bc6-97aa-11e5-b8df-14dae9d210b8 | django -- information leak vulnerability
Tim Graham reports:
If an application allows users to specify an unvalidated
format for dates and passes this format to the date filter, e.g. {{
last_updated|date:user_date_format }}, then a malicious user could
obtain any secret in the application's settings by specifying a settings
key instead of a date format. e.g. "SECRET_KEY" instead of "j/m/Y".
Discovery 2015-11-24 Entry 2015-11-30 Modified 2015-12-24 py27-django
py32-django
py33-django
py34-django
< 1.8.7
py27-django18
py32-django18
py33-django18
py34-django18
< 1.8.7
py27-django17
py32-django17
py33-django17
py34-django17
< 1.7.11
py27-django-devel
py32-django-devel
py33-django-devel
py34-django-devel
le 20150709,1
https://www.djangoproject.com/weblog/2015/nov/24/security-releases-issued/
CVE-2015-8213
|
b0e54dc1-45d2-11e5-adde-14dae9d210b8 | django -- multiple vulnerabilities
Tim Graham reports:
Denial-of-service possibility in logout() view by filling
session store
Previously, a session could be created when anonymously
accessing the django.contrib.auth.views.logout view
(provided it wasn't decorated with django.contrib.auth.decorators.login_required
as done in the admin). This could allow an attacker to
easily create many new session records by sending repeated
requests, potentially filling up the session store or
causing other users' session records to be evicted.
The django.contrib.sessions.middleware.SessionMiddleware
has been modified to no longer create empty session records.
This portion of the fix has been assigned CVE-2015-5963.
Additionally, on the 1.4 and 1.7 series only, the
contrib.sessions.backends.base.SessionBase.flush() and
cache_db.SessionStore.flush() methods have been modified
to avoid creating a new empty session. Maintainers of
third-party session backends should check if the same
vulnerability is present in their backend and correct
it if so.
This portion of the fix has been assigned CVE-2015-5964.
Anyone reporting a similar vulnerability in a third-party
session backend should not use this CVE ID.
Thanks Lin Hua Cheng for reporting the issue.
Discovery 2015-08-18 Entry 2015-08-18 py27-django
py32-django
py33-django
py34-django
< 1.8.4
py27-django17
py32-django17
py33-django17
py34-django17
< 1.7.10
py27-django14
py32-django14
py33-django14
py34-django14
< 1.4.22
py27-django-devel
py32-django-devel
py33-django-devel
py34-django-devel
le 20150709,1
https://www.djangoproject.com/weblog/2015/aug/18/security-releases/
CVE-2015-5963
CVE-2015-5964
|
f9e6c0d1-e4cc-11e5-b2bd-002590263bf5 | django -- multiple vulnerabilities
Tim Graham reports:
Malicious redirect and possible XSS attack via user-supplied
redirect URLs containing basic auth
User enumeration through timing difference on password hasher work
factor upgrade
Discovery 2016-03-01 Entry 2016-03-08 py27-django
py32-django
py33-django
py34-django
py35-django
< 1.8.10
py27-django18
py32-django18
py33-django18
py34-django18
py35-django18
< 1.8.10
py27-django19
py32-django19
py33-django19
py34-django19
py35-django19
< 1.9.3
py27-django-devel
py32-django-devel
py33-django-devel
py34-django-devel
py35-django-devel
le 20150709,1
CVE-2016-2512
CVE-2016-2513
https://www.djangoproject.com/weblog/2016/mar/01/security-releases/
|
dc880d6c-195d-11e7-8c63-0800277dcc69 | django -- multiple vulnerabilities
Django team reports:
These release addresses two security issues detailed below. We
encourage all users of Django to upgrade as soon as possible.
- Open redirect and possible XSS attack via user-supplied numeric
redirect URLs
- Open redirect vulnerability in django.views.static.serve()
Discovery 2017-04-04 Entry 2017-04-04 py27-django
py33-django
py34-django
py35-django
py36-django
< 1.8.18
py27-django18
py33-django18
py34-django18
py35-django18
py36-django18
< 1.8.18
py27-django19
py33-django19
py34-django19
py35-django19
py36-django19
< 1.9.13
py27-django110
py33-django110
py34-django110
py35-django110
py36-django110
< 1.10.7
https://www.djangoproject.com/weblog/2017/apr/04/security-releases/
CVE-2017-7233
CVE-2017-7234
|
f01292a0-db3c-11e1-a84b-00e0814cab4e | django -- multiple vulnerabilities
The Django project reports:
Today the Django team is issuing multiple releases --
Django 1.3.2 and Django 1.4.1 -- to remedy security issues
reported to us:
- Cross-site scripting in authentication views
- Denial-of-service in image validation
- Denial-of-service via get_image_dimensions()
All users are encouraged to upgrade Django immediately.
Discovery 2012-07-30 Entry 2012-07-31 Modified 2014-04-30 py26-django
ge 1.4 lt 1.4.1
ge 1.3 lt 1.3.2
py27-django
ge 1.4 lt 1.4.1
ge 1.3 lt 1.3.2
py26-django-devel
< 20120731,1
py27-django-devel
< 20120731,1
CVE-2012-3442
CVE-2012-3443
CVE-2012-3444
https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued/
|