FreshPorts - VuXML

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

< 1.8.10

< 1.8.10

< 1.9.3

le 20150709,1

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

< 1.8.16

< 1.8.16

< 1.9.11

< 1.10.3

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()

< 1.8.18

< 1.8.18

< 1.9.13

< 1.10.7

The Django project reports:

Please reference CVE/URL list for details

ge 1.3 lt 1.3.1

ge 1.2 lt 1.2.7

< 16758,1

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.

< 1.8.4

< 1.7.10

< 1.4.22

le 20150709,1

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".

< 1.8.7

< 1.8.7

< 1.7.11

le 20150709,1