CVSS: 7.8EPSS: 0%CPEs: 16EXPL: 1CVE-2019-7548 – python-sqlalchemy: SQL Injection when the group_by parameter can be controlled
https://notcve.org/view.php?id=CVE-2019-7548
SQLAlchemy 1.2.17 has SQL Injection when the group_by parameter can be controlled. SQLAlchemy 1.2.17 tiene una inyección SQL cuando el parámetro group_by se puede controlar. • http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00087.html http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00010.html http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00016.html https://access.redhat.com/errata/RHSA-2019:0981 https://access.redhat.com/errata/RHSA-2019:0984 https://github.com/no-security/sqlalchemy_test https://github.com/sqlalchemy/sqlalchemy/issues/4481#issuecomment-461204518 https://lists.debian.org/debian-lts-announce/2019/03/msg0 • CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') •
CVSS: 7.5EPSS: 1%CPEs: 9EXPL: 2CVE-2019-6690 – Python GnuPG 0.4.3 Improper Input Validation
https://notcve.org/view.php?id=CVE-2019-6690
python-gnupg 0.4.3 allows context-dependent attackers to trick gnupg to decrypt other ciphertext than intended. To perform the attack, the passphrase to gnupg must be controlled by the adversary and the ciphertext should be trusted. Related to a "CWE-20: Improper Input Validation" issue affecting the affect functionality component. python-gnupg 0.4.3 permite que los atacantes dependientes del contexto engañen a gnupg para descifrar texto cifrado diferente al planeado. Para realizar el ataque, la frase de contraseña para gnupg debe estar controlada por el adversario y el texto cifrado debería ser fiable. Relacionado con un problema CWE-20: validación de entradas incorrecta que afecta al componente de la funcionalidad afectada. • https://github.com/brianwrf/CVE-2019-6690 https://github.com/stigtsp/CVE-2019-6690-python-gnupg-vulnerability http://lists.opensuse.org/opensuse-security-announce/2019-02/msg00008.html http://lists.opensuse.org/opensuse-security-announce/2019-02/msg00058.html http://packetstormsecurity.com/files/151341/Python-GnuPG-0.4.3-Improper-Input-Validation.html http://www.securityfocus.com/bid/106756 https://blog.hackeriet.no/cve-2019-6690-python-gnupg-vulnerability https://lists.debian.org/debian-lts-announ • CWE-20: Improper Input Validation •
CVSS: 8.1EPSS: 21%CPEs: 8EXPL: 0CVE-2018-16873
https://notcve.org/view.php?id=CVE-2018-16873
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious commands, they will execute on the system running "go get -u". • http://lists.opensuse.org/opensuse-security-announce/2019-03/msg00044.html http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00060.html http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00011.html http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00015.html http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00010.html http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00041.html http://www.securityfocus.com/bid/106226 https://bugzilla&# • CWE-20: Improper Input Validation •
CVSS: 8.1EPSS: 1%CPEs: 8EXPL: 0CVE-2018-16874
https://notcve.org/view.php?id=CVE-2018-16874
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to directory traversal when executed with the import path of a malicious Go package which contains curly braces (both '{' and '}' characters). Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Module_aware_go_get). The attacker can cause an arbitrary filesystem write, which can lead to code execution. En Go en versiones anteriores a la 1.10.6 y versiones 1.11.x anteriores a la 1.11.3, el comando "go get" es vulnerable a un salto de directorio cuando se ejecuta con la ruta de importación de un paquete Go malicioso que contiene llaves (ambos caracteres "{" y "}"). Específicamente, solo es vulnerable en modo GOPATH, pero no en modo módulo (la diferencia está documentada en https://golang.org/cmd/go/#hdr-Module_aware_go_get). • http://lists.opensuse.org/opensuse-security-announce/2019-03/msg00044.html http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00060.html http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00011.html http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00015.html http://lists.opensuse.org/opensuse-security-announce/2019-07/msg00010.html http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00041.html http://www.securityfocus.com/bid/106228 https://bugzilla&# • CWE-20: Improper Input Validation CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •
CVSS: 7.5EPSS: 0%CPEs: 13EXPL: 1CVE-2018-19052
https://notcve.org/view.php?id=CVE-2018-19052
An issue was discovered in mod_alias_physical_handler in mod_alias.c in lighttpd before 1.4.50. There is potential ../ path traversal of a single directory above an alias target, with a specific mod_alias configuration where the matched alias lacks a trailing '/' character, but the alias target filesystem path does have a trailing '/' character. Se ha descubierto un problema en mod_alias_physical_handler en mod_alias.c en lighttpd en versiones anteriores a la 1.4.50. Hay un salto de directorio ../ de un único directorio sobre el alias objetivo, con una configuración mod_alias específica en la que el alias coincidente carece de un carácter "/" final, pero el sistema de archivos del alias objetivo sí tiene un carácter "/" final. • http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00054.html https://github.com/lighttpd/lighttpd1.4/commit/2105dae0f9d7a964375ce681e53cb165375f84c1 https://lists.debian.org/debian-lts-announce/2022/01/msg00012.html • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •