CVSS: 7.8EPSS: 0%CPEs: 9EXPL: 0CVE-2018-10874 – ansible: Inventory variables are loaded from current working directory when running ad-hoc command that can lead to code execution
https://notcve.org/view.php?id=CVE-2018-10874
In ansible it was found that inventory variables are loaded from current working directory when running ad-hoc command which are under attacker's control, allowing to run arbitrary code as a result. En Ansible, se ha descubierto que las variables de inventario se cargan desde el directorio de trabajo actual cuando se ejecutan comandos ad-hoc bajo el control del atacante, lo que permite la ejecución de código arbitrario como resultado. • http://www.securitytracker.com/id/1041396 https://access.redhat.com/errata/RHBA-2018:3788 https://access.redhat.com/errata/RHSA-2018:2150 https://access.redhat.com/errata/RHSA-2018:2151 https://access.redhat.com/errata/RHSA-2018:2152 https://access.redhat.com/errata/RHSA-2018:2166 https://access.redhat.com/errata/RHSA-2018:2321 https://access.redhat.com/errata/RHSA-2018:2585 https://access.redhat.com/errata/RHSA-2019:0054 https://bugzilla.redhat.com/show_bug.cgi?id= • CWE-20: Improper Input Validation CWE-426: Untrusted Search Path •
CVSS: 5.9EPSS: 0%CPEs: 12EXPL: 0CVE-2018-10855 – ansible: Failed tasks do not honour no_log option allowing for secrets to be disclosed in logs
https://notcve.org/view.php?id=CVE-2018-10855
Ansible 2.5 prior to 2.5.5, and 2.4 prior to 2.4.5, do not honor the no_log task flag for failed tasks. When the no_log flag has been used to protect sensitive data passed to a task from being logged, and that task does not run successfully, Ansible will expose sensitive data in log files and on the terminal of the user running Ansible. Ansible, en versiones 2.5 anteriores a la 2.5.5 y 2.4 anteriores a la 2.4.5, no cumplen con la marca de tarea no_log para las tareas fallidas. Cuando se ha empleado la marca no_log para proteger datos sensibles que se pasan a una tarea desde que se registra y esa tarea no se ejecuta con éxito, Ansible mostrará datos sensibles en archivos de registro y en el terminal del usuario que ejecuta Ansible. • https://access.redhat.com/errata/RHBA-2018:3788 https://access.redhat.com/errata/RHSA-2018:1948 https://access.redhat.com/errata/RHSA-2018:1949 https://access.redhat.com/errata/RHSA-2018:2022 https://access.redhat.com/errata/RHSA-2018:2079 https://access.redhat.com/errata/RHSA-2018:2184 https://access.redhat.com/errata/RHSA-2018:2585 https://access.redhat.com/errata/RHSA-2019:0054 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10855 https://usn.ubuntu.com/ • CWE-532: Insertion of Sensitive Information into Log File •
CVSS: 9.8EPSS: 4%CPEs: 23EXPL: 2CVE-2018-7750 – Paramiko 2.4.1 - Authentication Bypass
https://notcve.org/view.php?id=CVE-2018-7750
transport.py in the SSH server implementation of Paramiko before 1.17.6, 1.18.x before 1.18.5, 2.0.x before 2.0.8, 2.1.x before 2.1.5, 2.2.x before 2.2.3, 2.3.x before 2.3.2, and 2.4.x before 2.4.1 does not properly check whether authentication is completed before processing other requests, as demonstrated by channel-open. A customized SSH client can simply skip the authentication step. transport.py en la implementación del servidor SSH de Paramiko, en versiones anteriores a la 1.17.6; versiones 1.18.x anteriores a la 1.18.5; versiones 2.0.x anteriores a la 2.0.8; versiones 2.1.x anteriores a la 2.1.5; versiones 2.2.x anteriores a la 2.2.3; versiones 2.3.x anteriores a la 2.3.2 y versiones 2.4.x anteriores a la 2.4.1, no comprueba adecuadamente si la autenticación se ha completado antes de procesar otras peticiones, tal y como demuestra channel-open. Un cliente SSH personalizado puede simplemente omitir el paso de autenticación. It was found that when acting as an SSH server, paramiko did not properly check whether authentication is completed before processing other requests. A customized SSH client could use this to bypass authentication when accessing any resources controlled by paramiko. • https://www.exploit-db.com/exploits/45712 https://github.com/jm33-m0/CVE-2018-7750 http://www.securityfocus.com/bid/103713 https://access.redhat.com/errata/RHSA-2018:0591 https://access.redhat.com/errata/RHSA-2018:0646 https://access.redhat.com/errata/RHSA-2018:1124 https://access.redhat.com/errata/RHSA-2018:1125 https://access.redhat.com/errata/RHSA-2018:1213 https://access.redhat.com/errata/RHSA-2018:1274 https://access.redhat.com/errata/RHSA-2018:1328 https:&#x • CWE-287: Improper Authentication •
CVSS: 4.9EPSS: 0%CPEs: 2EXPL: 0CVE-2016-8647 – Ansible: in some circumstances the mysql_user module may fail to correctly change a password
https://notcve.org/view.php?id=CVE-2016-8647
An input validation vulnerability was found in Ansible's mysql_user module before 2.2.1.0, which may fail to correctly change a password in certain circumstances. Thus the previous password would still be active when it should have been changed. Se ha detectado una vulnerabilidad de validación de entradas en el módulo mysql_user de Ansible en versiones anteriores a la 2.2.1.0, el cual puede fallar a la hora de cambiar correctamente una contraseña en determinadas circunstancias. Entonces, la contraseña anterior seguiría activa cuando se debería haber cambiado. An input validation vulnerability was found in Ansible's mysql_user module which may fail to correctly change a password in certain circumstances. • https://access.redhat.com/errata/RHSA-2017:1685 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-8647 https://github.com/ansible/ansible-modules-core/pull/5388 https://access.redhat.com/security/cve/CVE-2016-8647 https://bugzilla.redhat.com/show_bug.cgi?id=1396174 • CWE-20: Improper Input Validation •
CVSS: 9.8EPSS: 2%CPEs: 16EXPL: 0CVE-2017-7481 – ansible: Security issue with lookup return not tainting the jinja2 environment
https://notcve.org/view.php?id=CVE-2017-7481
Ansible before versions 2.3.1.0 and 2.4.0.0 fails to properly mark lookup-plugin results as unsafe. If an attacker could control the results of lookup() calls, they could inject Unicode strings to be parsed by the jinja2 templating system, resulting in code execution. By default, the jinja2 templating language is now marked as 'unsafe' and is not evaluated. Ansible en versiones anteriores a la 2.3.1.0 y 2.4.0.0 no marca correctamente los resultados del plugin lookup como no seguros. Si un atacante pudiese controlar los resultados de las llamadas lookup(), podrían inyectar cadenas Unicode para que sean analizadas por el sistema de plantillas jinja2, resultando en una ejecución de código. • http://www.securityfocus.com/bid/98492 https://access.redhat.com/errata/RHSA-2017:1244 https://access.redhat.com/errata/RHSA-2017:1334 https://access.redhat.com/errata/RHSA-2017:1476 https://access.redhat.com/errata/RHSA-2017:1499 https://access.redhat.com/errata/RHSA-2017:1599 https://access.redhat.com/errata/RHSA-2017:2524 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-7481 https://github.com/ansible/ansible/commit/ed56f51f185a1ffd7ea57130d260098686fcc7c2 https://lists.deb • CWE-20: Improper Input Validation •