Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
66 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A flaw was found in the Ansible Engine when the fetch module is used. An attacker could intercept the module, inject a new path, and then choose a new destination path on the controller node. All versions in 2.7.x, 2.8.x and 2.9.x branches are believed to be vulnerable.
Recommended action: Upgrade to 2.9.8, 2.8.12 or 2.7.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A security flaw was found in Ansible Engine, all Ansible 2.7.x versions prior to 2.7.17, all Ansible 2.8.x versions prior to 2.8.11 and all Ansible 2.9.x versions prior to 2.9.7, when managing kubernetes using the k8s module. Sensitive parameters such as passwords and tokens are passed to kubectl from the command line, not using an environment variable or an input configuration file. This will disclose passwords and tokens from process list and nolog directive from debug module would not have any effect making these secrets being disclosed on stdout and log files.
Recommended action: Upgrade to 2.9.7, 2.8.12 or 2.7.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in Ansible 2.7.16 and prior, 2.8.8 and prior, and 2.9.5 and prior when a password is set with the argument "password" of svn module, it is used on svn command line, disclosing to other users within the same node. An attacker could take advantage by reading the cmdline file from that particular PID on the procfs.
Recommended action: Upgrade to 2.9.7, 2.8.11 or 2.7.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in several ansible modules, where parameters containing credentials, such as secrets, were being logged in plain-text on managed nodes, as well as being made visible on the controller node when run in verbose mode. These parameters were not protected by the no_log feature. An attacker can take advantage of this information to steal those credentials, provided when they have access to the log files containing them. The highest threat from this vulnerability is to data confidentiality. This flaw affects Red Hat Ansible Automation Platform in versions before 1.2.2 and Ansible Tower in versions before 3.8.2.
Recommended action: Upgrade to 1.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible, versions 2.9.x before 2.9.1, 2.8.x before 2.8.7 and Ansible versions 2.7.x before 2.7.15, is not respecting the flag nolog set it to True when Sumologic and Splunk callback plugins are used send tasks results events to collectors. This would discloses and collects any sensitive data.
Recommended action: Upgrade to 2.9.1, 2.8.7 or 2.7.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was discovered in the way Ansible templating was implemented in versions before 2.6.18, 2.7.12 and 2.8.2, causing the possibility of information disclosure through unexpected variable substitution. By taking advantage of unintended variable substitution the content of any variable may be disclosed.
Recommended action: Upgrade to 2.8.2, 2.7.12 or 2.6.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible fetch module before versions 2.5.15, 2.6.14, 2.7.8 has a path traversal vulnerability which allows copying and overwriting files outside of the specified destination in the local ansible controller host, by not restricting an absolute path.
Recommended action: Upgrade to 2.7.8, 2.6.14 or 2.5.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible before 1.9.2 does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
Recommended action: Upgrade to 1.9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The createscript function in the lxccontainer module in Ansible before 1.9.6-1 and 2.x before 2.0.2.0 allows local users to write to arbitrary files or gain privileges via a symlink attack on (1) /opt/.lxc-attach-script, (2) the archived container in the archivepath directory, or the (3) lxc-attach-script.log or (4) lxc-attach-script.err files in the temporary directory.
Recommended action: Upgrade to 2.0.2.0 or 1.9.6.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible before 1.2.1 makes it easier for remote attackers to conduct man-in-the-middle attacks by leveraging failure to cache SSH host keys.
Recommended action: Upgrade to 1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An input validation vulnerability was found in Ansible's mysqluser 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.
Recommended action: Upgrade to 2.2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in Ansible before version 2.2.0.0. The aptkey module does not properly verify key fingerprints, allowing remote adversary to create an OpenPGP key which matches the short key ID and inject this key instead of the correct key.
Recommended action: Upgrade to 2.2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible 2.5 prior to 2.5.5, and 2.4 prior to 2.4.5, do not honor the nolog task flag for failed tasks. When the nolog 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.
Recommended action: Upgrade to 2.5.5 or 2.4.5.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible before version 2.2.0 fails to properly sanitize fact variables sent from the Ansible controller. An attacker with the ability to create special variables on the controller could execute arbitrary commands on Ansible clients as the user Ansible runs as.
Recommended action: Upgrade to 2.2.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible before versions 2.1.4.0, 2.2.1.0 is vulnerable to an improper input validation in Ansible's handling of data sent from client systems. An attacker with control over a client system being managed by Ansible and the ability to send facts back to the Ansible server could use this flaw to execute arbitrary code on the Ansible server using the Ansible server privileges.
Recommended action: Upgrade to 2.2.1.0 or 2.1.4.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible before versions 2.1.6.0, 2.2.3.0, 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.
Recommended action: Upgrade to 2.3.1.0, 2.2.3.0 or 2.1.6.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.