FreshPorts - VuXML

This page displays vulnerability information about FreeBSD Ports.

The VUXML data was last processed by FreshPorts on 2024-03-28 15:43:32 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
1685144e-63ff-11ea-a93a-080027846a02Django -- potential SQL injection vulnerability

MITRE CVE reports:

Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a tolerance parameter in GIS functions and aggregates on Oracle. By passing a suitably crafted tolerance to GIS functions and aggregates on Oracle, it was possible to break escaping and inject malicious SQL.


Discovery 2020-02-25
Entry 2020-03-12
py27-django111
py35-django111
py36-django111
py37-django111
py38-django111
< 1.11.29

py35-django22
py36-django22
py37-django22
py38-django22
< 2.2.11

py36-django30
py37-django30
py38-django30
< 3.0.4

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9402
https://www.djangoproject.com/weblog/2020/mar/04/security-releases/
CVE-2020-9402
3e41c1a6-10bc-11e9-bd85-fcaa147e860eDjango -- Content spoofing possibility in the default 404 page

Django security releases issued reports:

An attacker could craft a malicious URL that could make spoofed content appear on the default page generated by the django.views.defaults.page_not_found() view.


Discovery 2019-01-03
Entry 2019-01-05
py27-django111
py35-django111
py36-django111
py37-django111
< 1.11.18

py35-django20
py36-django20
py37-django20
< 2.0.10

py35-django21
py36-django21
py37-django21
< 2.1.5

CVE-2019-3498
https://www.djangoproject.com/weblog/2019/jan/04/security-releases/
5a45649a-4777-11ea-bdec-08002728f74cDjango -- potential SQL injection vulnerability

MITRE CVE reports:

Django 1.11 before 1.11.28, 2.2 before 2.2.10, and 3.0 before 3.0.3 allows SQL Injection if untrusted data is used as a StringAgg delimiter (e.g., in Django applications that offer downloads of data as a series of rows with a user-specified column delimiter). By passing a suitably crafted delimiter to a contrib.postgres.aggregates.StringAgg instance, it was possible to break escaping and inject malicious SQL.


Discovery 2020-02-03
Entry 2020-02-04
py27-django111
py35-django111
py36-django111
py37-django111
py38-django111
< 1.11.28

py35-django22
py36-django22
py37-django22
py38-django22
< 2.2.10

py36-django30
py37-django30
py38-django30
< 3.0.3

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7471
https://docs.djangoproject.com/en/1.11/releases/1.11.28/
https://docs.djangoproject.com/en/2.2/releases/2.2.10/
https://docs.djangoproject.com/en/3.0/releases/3.0.3/
CVE-2020-7471
6e65dfea-b614-11e9-a3a2-1506e15611ccDjango -- multiple vulnerabilities

Django release notes:

CVE-2019-14232: Denial-of-service possibility in django.utils.text.Truncator

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

The regular expressions used by Truncator have been simplified in order to avoid potential backtracking issues. As a consequence, trailing punctuation may now at times be included in the truncated output.

CVE-2019-14233: Denial-of-service possibility in strip_tags()

Due to the behavior of the underlying HTMLParser, django.utils.html.strip_tags() would be extremely slow to evaluate certain inputs containing large sequences of nested incomplete HTML entities. The strip_tags() method is used to implement the corresponding striptags template filter, which was thus also vulnerable.

strip_tags() now avoids recursive calls to HTMLParser when progress removing tags, but necessarily incomplete HTML entities, stops being made.

Remember that absolutely NO guarantee is provided about the results of strip_tags() being HTML safe. So NEVER mark safe the result of a strip_tags() call without escaping it first, for example with django.utils.html.escape().

CVE-2019-14234: SQL injection possibility in key and index lookups for JSONField/HStoreField

Key and index lookups for JSONField and key lookups for HStoreField were subject to SQL injection, using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to QuerySet.filter().

CVE-2019-14235: Potential memory exhaustion in django.utils.encoding.uri_to_iri()

If passed certain inputs, django.utils.encoding.uri_to_iri() could lead to significant memory usage due to excessive recursion when re-percent-encoding invalid UTF-8 octet sequences.

uri_to_iri() now avoids recursion when re-percent-encoding invalid UTF-8 octet sequences.


Discovery 2019-08-01
Entry 2019-08-03
py27-django111
py35-django111
py36-django111
py37-django111
< 1.11.23

py27-django21
py35-django21
py36-django21
py37-django21
< 2.1.11

py27-django22
py35-django22
py36-django22
py37-django22
< 2.2.4

https://docs.djangoproject.com/en/1.11/releases/1.11.23/
https://docs.djangoproject.com/en/2.1/releases/2.1.11/
https://docs.djangoproject.com/en/2.2/releases/2.2.4/
CVE-2019-14232
CVE-2019-14233
CVE-2019-14234
CVE-2019-14235
aaab03be-932d-11e7-92d8-4b26fc968492Django -- possible XSS in traceback section of technical 500 debug page

Django blog:

In older versions, HTML autoescaping was disabled in a portion of the template for the technical 500 debug page. Given the right circumstances, this allowed a cross-site scripting attack. This vulnerability shouldn't affect most production sites since you shouldn't run with DEBUG = True (which makes this page accessible) in your production settings.


Discovery 2017-09-05
Entry 2017-09-06
py27-django110
py34-django110
py35-django110
py36-django110
< 1.10.8

py27-django111
py34-django111
py35-django111
py36-django111
< 1.11.5

CVE-2017-12794
https://www.djangoproject.com/weblog/2017/sep/05/security-releases/
b805d7b4-9c0c-11e9-97f0-000c29e96db4Django -- Incorrect HTTP detection with reverse-proxy connecting via HTTPS

Django security releases issued:

When deployed behind a reverse-proxy connecting to Django via HTTPS, django.http.HttpRequest.scheme would incorrectly detect client requests made via HTTP as using HTTPS. This entails incorrect results for is_secure(), and build_absolute_uri(), and that HTTP requests would not be redirected to HTTPS in accordance with SECURE_SSL_REDIRECT.


Discovery 2019-07-01
Entry 2019-07-01
py27-django111
py35-django111
py36-django111
py37-django111
< 1.11.22

py35-django21
py36-django21
py37-django21
< 2.1.10

py35-django22
py36-django22
py37-django22
< 2.2.3

CVE-2019-12781
https://www.djangoproject.com/weblog/2019/jul/01/security-releases/
d696473f-9f32-42c5-a106-bf4536fb1f74Django -- information leakage

Django release notes:

CVE-2018-6188: Information leakage in AuthenticationForm

A regression in Django 1.11.8 made AuthenticationForm run its confirm_login_allowed() method even if an incorrect password is entered. This can leak information about a user, depending on what messages confirm_login_allowed() raises. If confirm_login_allowed() isn't overridden, an attacker enter an arbitrary username and see if that user has been set to is_active=False. If confirm_login_allowed() is overridden, more sensitive details could be leaked.

This issue is fixed with the caveat that AuthenticationForm can no longer raise the "This account is inactive." error if the authentication backend rejects inactive users (the default authentication backend, ModelBackend, has done that since Django 1.10). This issue will be revisited for Django 2.1 as a fix to address the caveat will likely be too invasive for inclusion in older versions.


Discovery 2018-02-01
Entry 2018-02-02
py27-django111
py34-django111
py35-django111
py36-django111
< 1.11.10

py27-django20
py34-django20
py35-django20
py36-django20
< 2.0.2

https://docs.djangoproject.com/en/1.11/releases/1.11.10/
https://docs.djangoproject.com/en/2.0/releases/2.0.2/
CVE-2018-6188
ffc73e87-87f0-11e9-ad56-fcaa147e860eDjango -- AdminURLFieldWidget XSS

Django security releases issued:

The clickable "Current URL" link generated by AdminURLFieldWidget displayed the provided value without validating it as a safe URL. Thus, an unvalidated value stored in the database, or a value provided as a URL query parameter payload, could result in an clickable JavaScript link..

jQuery before 3.4.0, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.


Discovery 2019-06-03
Entry 2019-06-06
py27-django111
py35-django111
py36-django111
py37-django111
< 1.11.21

py35-django21
py36-django21
py37-django21
< 2.1.9

py35-django22
py36-django22
py37-django22
< 2.2.2

CVE-2019-12308
CVE-2019-11358
https://www.djangoproject.com/weblog/2019/jun/03/security-releases/