Page 10 of 103 results (0.019 seconds)

CVSS: 5.3EPSS: 0%CPEs: 11EXPL: 0

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. Se ha descubierto un problema en Django, en versiones 2.0 anteriores a la 2.0.3; versiones 1.11 anteriores a la 1.11.11 y versiones 1.8 anteriores a la 1.8.19. La función django.utils.html.urlize() fue extremadamente lenta a la hora de evaluar ciertas entradas debido a vulnerabilidades catastróficas de búsqueda hacia atrás en dos expresiones regulares (solo una en el caso de las versiones 1.8.x de Django). • http://www.securityfocus.com/bid/103361 https://access.redhat.com/errata/RHSA-2018:2927 https://access.redhat.com/errata/RHSA-2019:0051 https://access.redhat.com/errata/RHSA-2019:0082 https://access.redhat.com/errata/RHSA-2019:0265 https://github.com/django/django/commit/1ca63a66ef3163149ad822701273e8a1844192c2 https://github.com/django/django/commit/abf89d729f210c692a50e0ad3f75fb6bec6fae16 https://github.com/django/django/commit/e157315da3ae7005fa0683ffc9751dbeca7306c8 https://lists.debian.org/debian-lts-announce/20 • CWE-185: Incorrect Regular Expression CWE-400: Uncontrolled Resource Consumption •

CVSS: 5.3EPSS: 1%CPEs: 9EXPL: 0

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. Se ha descubierto un problema en Django, en versiones 2.0 anteriores a la 2.0.3; versiones 1.11 anteriores a la 1.11.11 y versiones 1.8 anteriores a la 1.8.19. Si los métodos de django.utils.text.Truncator chars() y words() se pasaban al argumento html=True, eran extremadamente lentos a la hora de evaluar ciertas entradas debido a una vulnerabilidad catastrófica de búsqueda hacia atrás en una expresión regular. • http://www.securityfocus.com/bid/103357 https://access.redhat.com/errata/RHSA-2018:2927 https://access.redhat.com/errata/RHSA-2019:0265 https://lists.debian.org/debian-lts-announce/2018/03/msg00006.html https://usn.ubuntu.com/3591-1 https://www.debian.org/security/2018/dsa-4161 https://www.djangoproject.com/weblog/2018/mar/06/security-releases https://access.redhat.com/security/cve/CVE-2018-7537 https://bugzilla.redhat.com/show_bug.cgi?id=1549779 • CWE-185: Incorrect Regular Expression CWE-400: Uncontrolled Resource Consumption •

CVSS: 7.5EPSS: 0%CPEs: 5EXPL: 0

django.contrib.auth.forms.AuthenticationForm in Django 2.0 before 2.0.2, and 1.11.8 and 1.11.9, allows remote attackers to obtain potentially sensitive information by leveraging data exposure from the confirm_login_allowed() method, as demonstrated by discovering whether a user account is inactive. django.contrib.auth.forms.AuthenticationForm en Django 2.0 anterior a 2.0.2 y 1.11.8 y 1.11.9 permte que atacantes remotos obtengan información potencialmente sensible aprovechando la exposición de datos del método confirm_login_allowed(), tal y como se demuestra al descubrir si una cuenta de usuario está activa o no. • http://www.securitytracker.com/id/1040422 https://usn.ubuntu.com/3559-1 https://www.djangoproject.com/weblog/2018/feb/01/security-releases https://access.redhat.com/security/cve/CVE-2018-6188 https://bugzilla.redhat.com/show_bug.cgi?id=1538793 • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-209: Generation of Error Message Containing Sensitive Information •

CVSS: 6.1EPSS: 0%CPEs: 13EXPL: 0

In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, 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. En Django versiones 1.10.x anteriores a la 1.10.8 y versiones 1.11.x anteriores a la 1.11.5, se deshabilitó la función de autoescapado HTML en una parte de la plantilla para la página de depuración technical 500. En las condiciones adecuadas, esto permitiría un ataque de Cross-Site Scripting (XSS). • http://www.securityfocus.com/bid/100643 http://www.securitytracker.com/id/1039264 https://usn.ubuntu.com/3559-1 https://www.djangoproject.com/weblog/2017/sep/05/security-releases • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') •

CVSS: 6.1EPSS: 0%CPEs: 49EXPL: 0

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. Una URL maliciosa manipulada a una sitio Django (1.10 en versiones anteriores a 1.10.7, 1.9 en versiones anteriores a 1.9.13, y 1.8 en versiones anteriores a 1.8.18) que usa la vista ``django.views.static.serve()`` podría redirigir a cualquier otro dominio, también conocido como una vulnerabilidad de redirección abierta. • http://www.debian.org/security/2017/dsa-3835 http://www.securityfocus.com/bid/97401 http://www.securitytracker.com/id/1038177 https://www.djangoproject.com/weblog/2017/apr/04/security-releases • CWE-601: URL Redirection to Untrusted Site ('Open Redirect') •