CVSS: 5.9EPSS: 0%CPEs: 14EXPL: 0CVE-2020-13254 – django: potential data leakage via malformed memcached keys
https://notcve.org/view.php?id=CVE-2020-13254
An issue was discovered in Django 2.2 before 2.2.13 and 3.0 before 3.0.7. In cases where a memcached backend does not perform key validation, passing malformed cache keys could result in a key collision, and potential data leakage. Se detectó un problema en Django versiones 2.2 anteriores a 2.2.13 y versiones 3.0 anteriores a 3.0.7. En casos donde un backend memcached no lleva a cabo una comprobación de la clave, pasa claves de caché maliciosas que podría resultar en una colisión de claves y una potencial filtración de datos. A flaw was found in Django, where the memcached backend does not perform key validation and passes malformed keys. • https://docs.djangoproject.com/en/3.0/releases/security https://groups.google.com/d/msg/django-announce/pPEmb2ot4Fo/X-SMalYSBAAJ https://lists.debian.org/debian-lts-announce/2020/06/msg00016.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4A2AP4T7RKPBCLTI2NNQG3T6MINDUUMZ https://security.netapp.com/advisory/ntap-20200611-0002 https://usn.ubuntu.com/4381-1 https://usn.ubuntu.com/4381-2 https://www.debian.org/security/2020/dsa-4705 https:/&#x • CWE-200: Exposure of Sensitive Information to an Unauthorized Actor CWE-295: Improper Certificate Validation •
CVSS: 8.8EPSS: 18%CPEs: 11EXPL: 0CVE-2020-9402 – django: potential SQL injection via "tolerance" parameter in GIS functions and aggregates on Oracle
https://notcve.org/view.php?id=CVE-2020-9402
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. Django versiones 1.11 anteriores a 1.11.29, versiones 2.2 anteriores a 2.2.11 y versiones 3.0 anteriores a 3.0.4, permite una Inyección SQL si datos no confiables son usados como un parámetro tolerance en funciones GIS y agregados en Oracle. Al pasar una tolerancia diseñada adecuadamente hacia las funciones GIS y agregarlas en Oracle, esto hizo posible romper el escape e inyectar SQL malicioso. A SQL-injection flaw was found in python-django, where GIS functions and aggregates in Oracle did not correctly neutralize tolerance-parameter data. • https://docs.djangoproject.com/en/3.0/releases/security https://groups.google.com/forum/#%21topic/django-announce/fLUh_pOaKrY https://lists.debian.org/debian-lts-announce/2022/05/msg00035.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/4A2AP4T7RKPBCLTI2NNQG3T6MINDUUMZ https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UZMN2NKAGTFE3YKMNM2JVJG7R2W7LLHY https://security.gentoo.org/glsa/202004-17 https://security.netapp.com/advis • CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') •
CVSS: 9.8EPSS: 1%CPEs: 3EXPL: 4CVE-2020-7471
https://notcve.org/view.php?id=CVE-2020-7471
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. Django versiones 1.11 anteriores a 1.11.28, versiones 2.2 anteriores a 2.2.10 y versiones 3.0 anteriores a 3.0.3, permite una Inyección SQL si se usan datos no confiables como un delimitador de StringAgg (por ejemplo, en aplicaciones Django que ofrecen descargas de datos como una serie de filas con un delimitador de columna especificado por el usuario). Al pasar un delimitador apropiadamente diseñado a una instancia contrib.postgres.aggregates.StringAgg, fue posible romper el escape e inyectar SQL malicioso. • https://github.com/Saferman/CVE-2020-7471 https://github.com/SNCKER/CVE-2020-7471 https://github.com/mrlihd/CVE-2020-7471 https://github.com/huzaifakhan771/CVE-2020-7471-Django http://www.openwall.com/lists/oss-security/2020/02/03/1 https://docs.djangoproject.com/en/3.0/releases/security https://github.com/django/django/commit/eb31d845323618d688ad429479c6dda973056136 https://groups.google.com/forum/#%21topic/django-announce/X45S86X5bZI https://lists.fedoraproject.org/archives/list/pac • CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') •
CVSS: 9.8EPSS: 22%CPEs: 7EXPL: 1CVE-2019-19844 – Django < 3.0 < 2.2 < 1.11 - Account Hijack
https://notcve.org/view.php?id=CVE-2019-19844
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. A suitably crafted email address (that is equal to an existing user's email address after case transformation of Unicode characters) would allow an attacker to be sent a password reset token for the matched user account. (One mitigation in the new releases is to send password reset tokens only to the registered user email address.) Django versiones anteriores a 1.11.27, versiones 2.x anteriores a 2.2.9 y versiones 3.x anteriores a 3.0.1, permite tomar el control de la cuenta. Una dirección de correo electrónico diseñada adecuadamente (que es igual a la dirección de correo electrónico de un usuario existente después de la transformación de mayúsculas y minúsculas de los caracteres Unicode) permitiría a un atacante enviarle un token de restablecimiento de contraseña para la cuenta de usuario coincidente. • https://www.exploit-db.com/exploits/47879 http://packetstormsecurity.com/files/155872/Django-Account-Hijack.html https://docs.djangoproject.com/en/dev/releases/security https://groups.google.com/forum/#%21topic/django-announce/3oaB2rVH3a0 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/HCM2DPUI7TOZWN4A6JFQFUVQ2XGE7GUD https://seclists.org/bugtraq/2020/Jan/9 https://security.gentoo.org/glsa/202004-17 https://security.netapp.com/advisory/ntap-20200110-0003 https& • CWE-640: Weak Password Recovery Mechanism for Forgotten Password •
CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0CVE-2019-19118
https://notcve.org/view.php?id=CVE-2019-19118
Django 2.1 before 2.1.15 and 2.2 before 2.2.8 allows unintended model editing. A Django model admin displaying inline related models, where the user has view-only permissions to a parent model but edit permissions to the inline model, would be presented with an editing UI, allowing POST requests, for updating the inline model. Directly editing the view-only parent model was not possible, but the parent model's save() method was called, triggering potential side effects, and causing pre and post-save signal handlers to be invoked. (To resolve this, the Django admin is adjusted to require edit permissions on the parent model in order for inline models to be editable.) Django versiones 2.1 anteriores a 2.1.15 y versiones 2.2 anteriores a 2.2.8, permite una edición de modelos involuntaria. • http://www.openwall.com/lists/oss-security/2019/12/02/1 https://docs.djangoproject.com/en/dev/releases/security https://groups.google.com/forum/#%21topic/django-announce/GjGqDvtNmWQ https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6R4HD22PVEVQ45H2JA2NXH443AYJOPL5 https://security.gentoo.org/glsa/202004-17 https://security.netapp.com/advisory/ntap-20191217-0003 https://www.djangoproject.com/weblog/2019/dec/02/security-releases • CWE-276: Incorrect Default Permissions •