Page 17 of 100 results (0.029 seconds)

CVSS: 5.0EPSS: 2%CPEs: 29EXPL: 0

The get_image_dimensions function in the image-handling functionality in Django before 1.3.2 and 1.4.x before 1.4.1 uses a constant chunk size in all attempts to determine dimensions, which allows remote attackers to cause a denial of service (process or thread consumption) via a large TIFF image. La función get_image_dimensions en la funcionalidad image-handling en Django anteriores a v1.3.2 y v1.4.x anteriores a v1.4.1 un tamaño de trozo constante en todos los intentos por determinar las dimensiones, lo que permitiría a atacantes remotos a provocar una denegación de servicio (consumo del proceso o hilo) a través de una imagen TIFF grande. • http://www.debian.org/security/2012/dsa-2529 http://www.mandriva.com/security/advisories?name=MDVSA-2012:143 http://www.openwall.com/lists/oss-security/2012/07/31/1 http://www.openwall.com/lists/oss-security/2012/07/31/2 http://www.ubuntu.com/usn/USN-1560-1 https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •

CVSS: 5.8EPSS: 1%CPEs: 22EXPL: 0

django.contrib.sessions in Django before 1.2.7 and 1.3.x before 1.3.1, when session data is stored in the cache, uses the root namespace for both session identifiers and application-data keys, which allows remote attackers to modify a session by triggering use of a key that is equal to that session's identifier. django.contrib.sessions en Django v1.2.7 y v1.3.x antereiores a v1.3.1, cuando los datos de sesión se almacena en la caché, utiliza el espacio de nombres raíz de los identificadores de sesión las teclas y los datos de aplicación, lo que permite a atacantes remotos modificar un sesión mediante la activación de uso de una clave que es igual al identificador de sesión. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-20: Improper Input Validation •

CVSS: 6.8EPSS: 0%CPEs: 22EXPL: 0

The CSRF protection mechanism in Django through 1.2.7 and 1.3.x through 1.3.1 does not properly handle web-server configurations supporting arbitrary HTTP Host headers, which allows remote attackers to trigger unauthenticated forged requests via vectors involving a DNS CNAME record and a web page containing JavaScript code. El mecanismo de protección ante CSRF de Django hasta la versión 1.2.7 y 1.3.x hasta la 1.3.1 no maneja apropiadamente las configuraciones del servidor web que soportan cabeceras HTTP Host arbitrarias, lo que permite a atacantes remotos provocar peticiones falsificadas sin autenticar a través de vectores que involucran un registro DNS CNAME y una página web que contenga código JavaScript. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-352: Cross-Site Request Forgery (CSRF) •

CVSS: 5.0EPSS: 1%CPEs: 22EXPL: 0

Django before 1.2.7 and 1.3.x before 1.3.1 uses a request's HTTP Host header to construct a full URL in certain circumstances, which allows remote attackers to conduct cache poisoning attacks via a crafted request. Django v1.2.7 y v1.3.x anterior a v1.3.1 usa la cabecera de una petición HTTP host para la construcción de una dirección URL completa, en determinadas circunstancias, lo que permite a atacantes remotos para realizar ataques de envenenamiento de caché a través de una solicitud manipulada. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-20: Improper Input Validation •

CVSS: 5.0EPSS: 0%CPEs: 22EXPL: 0

The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before 1.3.1 originally tests a URL's validity through a HEAD request, but then uses a GET request for the new target URL in the case of a redirect, which might allow remote attackers to trigger arbitrary GET requests with an unintended source IP address via a crafted Location header. La funcionalidad verify_exists de la implementación URLField en Django antes de su versión v1.2.7 y en v1.3.x antes de v1.3.1 originalmente comprueba la validez de una URL a través de una petición HEAD, pero luego usa una petición GET de la URL en el caso de un redireccionamiento. Esto podría permitir a atacantes remotos para provocar peticiones GET aleatorias con una dirección IP de origen no deseados a través de una cabecera Location especificamente modificada. • http://openwall.com/lists/oss-security/2011/09/11/1 http://openwall.com/lists/oss-security/2011/09/13/2 http://secunia.com/advisories/46614 http://www.debian.org/security/2011/dsa-2332 https://bugzilla.redhat.com/show_bug.cgi?id=737366 https://hermes.opensuse.org/messages/14700881 https://www.djangoproject.com/weblog/2011/sep/09 https://www.djangoproject.com/weblog/2011/sep/10/127 • CWE-20: Improper Input Validation •