FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The VUXML data was last processed by FreshPorts on 2024-03-29 07:54:42 UTC

List all Vulnerabilities, by package

List all Vulnerabilities, by date

k68

These are the vulnerabilities relating to the commit you have selected:

VuXML IDDescription
f9e6c0d1-e4cc-11e5-b2bd-002590263bf5django -- 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/
48504af7-07ad-11e5-879c-00e0814cab4edjango -- Fixed session flushing in the cached_db backend

The Django project reports:

A change to session.flush() in the cached_db session backend in Django 1.8 mistakenly sets the session key to an empty string rather than None. An empty string is treated as a valid session key and the session cookie is set accordingly. Any users with an empty string in their session cookie will use the same session store. session.flush() is called by django.contrib.auth.logout() and, more seriously, by django.contrib.auth.login() when a user switches accounts. If a user is logged in and logs in again to a different account (without logging out) the session is flushed to avoid reuse. After the session is flushed (and its session key becomes '') the account details are set on the session and the session is saved. Any users with an empty string in their session cookie will now be logged into that account.

Thanks to Sam Cooke for reporting the issue.


Discovery 2015-05-20
Entry 2015-05-31
py27-django
ge 1.8 lt 1.8.2

py32-django
ge 1.8 lt 1.8.2

py33-django
ge 1.8 lt 1.8.2

py34-django
ge 1.8 lt 1.8.2

py27-django-devel
< 20150531,1

py32-django-devel
< 20150531,1

py33-django-devel
< 20150531,1

py34-django-devel
< 20150531,1

https://www.djangoproject.com/weblog/2015/may/20/security-release/
CVE-2015-3982
62287f51-d43d-11e4-879c-00e0814cab4edjango -- multiple vulnerabilities

The Django project reports:

In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.4.20, 1.6.11, 1.7.7 and 1.8c1. These releases are now available on PyPI and our download page. These releases address several security issues detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.


Discovery 2015-03-18
Entry 2015-03-27
py27-django
ge 1.4 lt 1.4.20

ge 1.6 lt 1.6.11

ge 1.7 lt 1.7.7

py32-django
ge 1.4 lt 1.4.20

ge 1.6 lt 1.6.11

ge 1.7 lt 1.7.7

py33-django
ge 1.4 lt 1.4.20

ge 1.6 lt 1.6.11

ge 1.7 lt 1.7.7

py34-django
ge 1.4 lt 1.4.20

ge 1.6 lt 1.6.11

ge 1.7 lt 1.7.7

py27-django-devel
< 20150326,1

py32-django-devel
< 20150326,1

py33-django-devel
< 20150326,1

py34-django-devel
< 20150326,1

https://www.djangoproject.com/weblog/2015/mar/18/security-releases/
CVE-2015-2316
CVE-2015-2317
6b1d8a39-ddb3-11e5-8fa8-14dae9d210b8django -- regression in permissions model

Tim Graham reports:

User with "change" but not "add" permission can create objects for ModelAdmin’s with save_as=True


Discovery 2016-02-01
Entry 2016-02-28
py27-django19
py33-django19
py34-django19
py35-django19
< 1.9.2

py27-django-devel
py33-django-devel
py34-django-devel
py35-django-devel
le 20150709,1

https://www.djangoproject.com/weblog/2016/feb/01/releases-192-and-189/
CVE-2016-2048
9c7b6c20-a324-11e4-879c-00e0814cab4edjango -- multiple vulnerabilities

The Django project reports:

Today the Django team is issuing multiple releases -- Django 1.4.18, Django 1.6.10, and Django 1.7.3 -- as part of our security process. These releases are now available on PyPI and our download page.

These releases address several security issues. We encourage all users of Django to upgrade as soon as possible.


Discovery 2015-01-13
Entry 2015-01-23
Modified 2015-01-24
py27-django
ge 1.4 lt 1.4.18

ge 1.5 le 1.5.12

ge 1.6 lt 1.6.10

ge 1.7 lt 1.7.3

py32-django
ge 1.4 lt 1.4.18

ge 1.5 le 1.5.12

ge 1.6 lt 1.6.10

ge 1.7 lt 1.7.3

py33-django
ge 1.4 lt 1.4.18

ge 1.5 le 1.5.12

ge 1.6 lt 1.6.10

ge 1.7 lt 1.7.3

py34-django
ge 1.4 lt 1.4.18

ge 1.5 le 1.5.12

ge 1.6 lt 1.6.10

ge 1.7 lt 1.7.3

py27-django-devel
< 20150124,1

py32-django-devel
< 20150124,1

py33-django-devel
< 20150124,1

py34-django-devel
< 20150124,1

https://www.djangoproject.com/weblog/2015/jan/13/security/
CVE-2015-0219
CVE-2015-0220
CVE-2015-0221
CVE-2015-0222
3c5579f7-294a-11e4-99f6-00e0814cab4edjango -- multiple vulnerabilities

The Django project reports:

These releases address an issue with reverse() generating external URLs; a denial of service involving file uploads; a potential session hijacking issue in the remote-user middleware; and a data leak in the administrative interface. We encourage all users of Django to upgrade as soon as possible.


Discovery 2014-08-20
Entry 2014-08-21
py27-django
ge 1.6 lt 1.6.6

py27-django15
ge 1.5 lt 1.5.9

py27-django14
ge 1.4 lt 1.4.14

py32-django
ge 1.6 lt 1.6.6

py32-django15
ge 1.5 lt 1.5.9

py33-django
ge 1.6 lt 1.6.6

py33-django15
ge 1.5 lt 1.5.9

py34-django
ge 1.6 lt 1.6.6

py34-django15
ge 1.5 lt 1.5.9

py27-django-devel
< 20140821,1

py32-django-devel
< 20140821,1

py33-django-devel
< 20140821,1

py34-django-devel
< 20140821,1

https://www.djangoproject.com/weblog/2014/aug/20/security/
CVE-2014-0480
CVE-2014-0481
CVE-2014-0482
CVE-2014-0483
11c52bc6-97aa-11e5-b8df-14dae9d210b8django -- 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
37ed8e9c-2651-11e5-86ff-14dae9d210b8django -- multiple vulnerabilities

Tim Graham reports:

In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.4.21, 1.7.9, and 1.8.3. These releases are now available on PyPI and our download page. These releases address several security issues detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.


Discovery 2015-06-10
Entry 2015-07-09
py27-django
ge 1.4.0 lt 1.4.21

py32-django
ge 1.4.0 lt 1.4.21

py33-django
ge 1.4.0 lt 1.4.21

py34-django
ge 1.4.0 lt 1.4.21

py27-django
ge 1.7.0 lt 1.7.9

py32-django
ge 1.7.0 lt 1.7.9

py33-django
ge 1.7.0 lt 1.7.9

py34-django
ge 1.7.0 lt 1.7.9

py27-django
ge 1.8.0 lt 1.8.3

py32-django
ge 1.8.0 lt 1.8.3

py33-django
ge 1.8.0 lt 1.8.3

py34-django
ge 1.8.0 lt 1.8.3

py27-django-devel
le 20150531,1

py32-django-devel
le 20150531,1

py33-django-devel
le 20150531,1

py34-django-devel
le 20150531,1

https://www.djangoproject.com/weblog/2015/jul/08/security-releases/
https://github.com/django/django/commit/df049ed77a4db67e45db5679bfc76a85d2a26680
https://github.com/django/django/commit/014247ad1922931a2f17beaf6249247298e9dc44
https://github.com/django/django/commit/17d3a6d8044752f482453f5906026eaf12c39e8e
CVE-2015-5143
CVE-2015-5144
CVE-2015-5145
b0e54dc1-45d2-11e5-adde-14dae9d210b8django -- 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