CVSS: 5.3EPSS: 1%CPEs: 9EXPL: 0CVE-2018-7537 – django: Catastrophic backtracking in regular expressions via 'truncatechars_html' and 'truncatewords_html'
https://notcve.org/view.php?id=CVE-2018-7537
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: 0CVE-2018-6188 – django: Information leakage in AuthenticationForm
https://notcve.org/view.php?id=CVE-2018-6188
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: 0CVE-2017-12794
https://notcve.org/view.php?id=CVE-2017-12794
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') •