Total
25 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2018-16837 | 3 Debian, Redhat, Suse | 5 Debian Linux, Ansible Engine, Ansible Tower and 2 more | 2023-12-10 | 2.1 LOW | 7.8 HIGH |
| Ansible "User" module leaks any data which is passed on as a parameter to ssh-keygen. This could lean in undesirable situations such as passphrases credentials passed as a parameter for the ssh-keygen executable. Showing those credentials in clear text form for every user which have access just to the process list. | |||||
| CVE-2017-7481 | 3 Canonical, Debian, Redhat | 10 Ubuntu Linux, Debian Linux, Ansible Engine and 7 more | 2023-12-10 | 7.5 HIGH | 9.8 CRITICAL |
| 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. | |||||
| CVE-2018-7750 | 3 Debian, Paramiko, Redhat | 11 Debian Linux, Paramiko, Ansible Engine and 8 more | 2023-12-10 | 7.5 HIGH | 9.8 CRITICAL |
| 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. | |||||
| CVE-2018-10874 | 1 Redhat | 4 Ansible Engine, Openstack, Virtualization and 1 more | 2023-12-10 | 4.6 MEDIUM | 7.8 HIGH |
| 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. | |||||
| CVE-2018-10855 | 3 Canonical, Debian, Redhat | 6 Ubuntu Linux, Debian Linux, Ansible Engine and 3 more | 2023-12-10 | 4.3 MEDIUM | 5.9 MEDIUM |
| 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. | |||||