Page 5 of 79 results (0.008 seconds)

CVSS: 9.8EPSS: 1%CPEs: 36EXPL: 0

Django 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3 use a hardcoded password for a temporary database user created when running tests with an Oracle database, which makes it easier for remote attackers to obtain access to the database server by leveraging failure to manually specify a password in the database settings TEST dictionary. Django 1.8.x en versiones anteriores a 1.8.16, 1.9.x en versiones anteriores a 1.9.11 y 1.10.x en versiones anteriores a 1.10.3 utiliza una contraseña embebida para un usuario de base de datos temporal creada al ejecutar pruebas con una base de datos Oracle, lo que hace más fácil a atacantes remotos obtener acceso al servidor de la base de datos aprovechando el fallo para especificar manualmente una contraseña en la configuración del diccionario TEST de la base de datos. • http://www.debian.org/security/2017/dsa-3835 http://www.securityfocus.com/bid/94069 http://www.securitytracker.com/id/1037159 http://www.ubuntu.com/usn/USN-3115-1 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OG5ROMUPS6C7BXELD3TAUUH7OBYV56WQ https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QXDKJYHN74BWY3P7AR2UZDVJREQMRE6S https://www.djangoproject.com/weblog/2016/nov/01/security-releases • CWE-798: Use of Hard-coded Credentials •

CVSS: 8.1EPSS: 1%CPEs: 36EXPL: 0

Django before 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3, when settings.DEBUG is True, allow remote attackers to conduct DNS rebinding attacks by leveraging failure to validate the HTTP Host header against settings.ALLOWED_HOSTS. Django en versiones anteriores a 1.8.x en versiones anteriores a 1.8.16, 1.9.x en versiones anteriores a 1.9.11 y 1.10.x en versiones anteriores a 1.10.3 cuando settings.DEBUG es True, permiten a atacantes remotos llevar a cabo ataques de revinculación DNS aprovechando el fallo para validar la cabecera del Host HTTP contra settings.ALLOWED_HOSTS. • http://www.debian.org/security/2017/dsa-3835 http://www.securityfocus.com/bid/94068 http://www.securitytracker.com/id/1037159 http://www.ubuntu.com/usn/USN-3115-1 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OG5ROMUPS6C7BXELD3TAUUH7OBYV56WQ https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QXDKJYHN74BWY3P7AR2UZDVJREQMRE6S https://www.djangoproject.com/weblog/2016/nov/01/security-releases • CWE-264: Permissions, Privileges, and Access Controls •

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

The cookie parsing code in Django before 1.8.15 and 1.9.x before 1.9.10, when used on a site with Google Analytics, allows remote attackers to bypass an intended CSRF protection mechanism by setting arbitrary cookies. El código de análisis de cookie en Django en versiones anteriores a 1.8.15 y 1.9.x en versiones anteriores a 1.9.10, cuando se utiliza en un sitio con Google Analytics, permite a atacantes remotos eludir un mecanismo de protección CSRF destinado estableciendo cookies arbitrarias. A CSRF flaw was found in Django, where an interaction between Google Analytics and Django's cookie parsing could allow an attacker to set arbitrary cookies leading to a bypass of CSRF protection. In this update, the parser for ''request.COOKIES'' has been simplified to better match browser behavior and to mitigate this attack. ''request.COOKIES'' may now contain cookies that are invalid according to RFC 6265 but are possible to set using ''document.cookie''. • http://rhn.redhat.com/errata/RHSA-2016-2038.html http://rhn.redhat.com/errata/RHSA-2016-2039.html http://rhn.redhat.com/errata/RHSA-2016-2040.html http://rhn.redhat.com/errata/RHSA-2016-2041.html http://rhn.redhat.com/errata/RHSA-2016-2042.html http://rhn.redhat.com/errata/RHSA-2016-2043.html http://www.debian.org/security/2016/dsa-3678 http://www.securityfocus.com/bid/93182 http://www.securitytracker.com/id/1036899 http://www.ubuntu.com/usn/USN-3089- • CWE-254: 7PK - Security Features CWE-352: Cross-Site Request Forgery (CSRF) •

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

Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/js/admin/RelatedObjectLookups.js in Django before 1.8.14, 1.9.x before 1.9.8, and 1.10.x before 1.10rc1 allows remote attackers to inject arbitrary web script or HTML via vectors involving unsafe usage of Element.innerHTML. Vulnerabilidad de XSS en la función dismissChangeRelatedObjectPopup en contrib/admin/static/admin/js/admin/RelatedObjectLookups.js en Django en versiones anteriores a 1.8.14, 1.9.x en versiones anteriores a 1.9.8 y 1.10.x en versiones anteriores a 1.10rc1 permite a atacantes remotos inyectar secuencias de comandos web o HTML arbitrarios a través de vectors relacionados con el uso no seguro de Element.innerHTML. A cross-site scripting (XSS) flaw was found in Django. An attacker could exploit the unsafe usage of JavaScript's Element.innerHTML to forge content in the admin's add/change related pop-up. Element.textContent is now used to prevent XSS data execution. • https://www.exploit-db.com/exploits/40129 http://packetstormsecurity.com/files/137965/Django-3.3.0-Script-Insertion.html http://rhn.redhat.com/errata/RHSA-2016-1594.html http://rhn.redhat.com/errata/RHSA-2016-1595.html http://rhn.redhat.com/errata/RHSA-2016-1596.html http://seclists.org/fulldisclosure/2016/Jul/53 http://www.debian.org/security/2016/dsa-3622 http://www.securityfocus.com/archive/1/538947/100/0/threaded http://www.securityfocus.com/bid/92058 http:/& • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') •

CVSS: 7.4EPSS: 0%CPEs: 4EXPL: 0

The utils.http.is_safe_url function in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks or possibly conduct cross-site scripting (XSS) attacks via a URL containing basic authentication, as demonstrated by http://mysite.example.com\@attacker.com. La función utils.http.is_safe_url en Django en versiones anteriores a 1.8.10 y 1.9.x en versiones anteriores a 1.9.3 permite a atacantes remotos redirigir a usuarios a páginas web arbitrarias y llevar a cabo ataques de phishing o posiblemente llevar a cabo ataques de XSS a través de una URL que contiene autenticación básica, según lo demostrado por http://mysite.example.com\@attacker.com. An open-redirect flaw was found in the way Django's django.utils.http.is_safe_url() function filtered authentication URLs. An attacker able to trick a victim into visiting a crafted URL could use this flaw to redirect that victim to a malicious site. • http://rhn.redhat.com/errata/RHSA-2016-0502.html http://rhn.redhat.com/errata/RHSA-2016-0504.html http://rhn.redhat.com/errata/RHSA-2016-0505.html http://rhn.redhat.com/errata/RHSA-2016-0506.html http://www.debian.org/security/2016/dsa-3544 http://www.oracle.com/technetwork/topics/security/bulletinapr2016-2952098.html http://www.securityfocus.com/bid/83879 http://www.securitytracker.com/id/1035152 http://www.ubuntu.com/usn/USN-2915-1 http://www.ubuntu.com/usn&#x • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CWE-601: URL Redirection to Untrusted Site ('Open Redirect') •