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.
ansible before versions 2.5.14, 2.6.11, 2.7.5 is vulnerable to a information disclosure flaw in vvv+ mode with nolog on that can lead to leakage of sensible data.
Recommended action: Upgrade to 2.7.5, 2.6.11 or 2.5.14 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.3 has an input validation vulnerability in the 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.3.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 the way Ansible (2.3.x before 2.3.3, and 2.4.x before 2.4.1) passed certain parameters to the jenkinsplugin module. Remote attackers could use this flaw to expose sensitive information from a remote host's logs. This flaw was fixed by not allowing passwords to be specified in the "params" argument, and noting this in the module documentation.
Recommended action: Upgrade to 2.4.1.0 or 2.3.3.0 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 module where credentials are disclosed in the console log by default and not protected by the security feature when using the bitbucketpipelinevariable module. This flaw allows an attacker to steal bitbucketpipeline credentials. The highest threat from this vulnerability is to confidentiality.
Recommended action: Upgrade to 2.9.18 or 2.8.19 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Ansible is an IT automation system that handles configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation, and multi-node orchestration. A flaw was found in Ansible Engine's ansible-connection module where sensitive information, such as the Ansible user credentials, is disclosed by default in the traceback error message when Ansible receives an unexpected response from setoptions. The highest threat from this vulnerability is confidentiality.
Recommended action: Upgrade to 2.9.27 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An Improper Output Neutralization for Logs flaw was found in Ansible when using the uri module, where sensitive data is exposed to content and json output. This flaw allows an attacker to access the logs or outputs of performed tasks to read keys used in playbooks from other users within the uri module. The highest threat from this vulnerability is to data confidentiality.
Recommended action: Upgrade to 2.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An incomplete fix was found for the fix of the flaw CVE-2020-1733 ansible insecure temporary directory when running becomeuser from become directive. The provided fix is insufficient to prevent the race condition on systems using ACLs and FUSE filesystems. Ansible Engine 2.7.18, 2.8.12, and 2.9.9 as well as previous versions are affected and Ansible Tower 3.4.5, 3.5.6 and 3.6.4 as well as previous versions are affected.
Recommended action: Upgrade to 2.10.0rc1 (pre-release) or 2.9.12 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 the Ansible Engine when using moduleargs. Tasks executed with check mode (--check-mode) do not properly neutralize sensitive data exposed in the event data. This flaw allows unauthorized users to read this data. The highest threat from this vulnerability is to confidentiality.
Recommended action: Upgrade to 2.10.1rc2 (pre-release), 2.9.12 or 2.8.14 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 the pipe lookup plugin of ansible. Arbitrary commands can be run, when the pipe lookup plugin uses subprocess.Popen() with shell=True, by overwriting ansible facts and the variable is not escaped by quote plugin. An attacker could take advantage and run arbitrary commands by overwriting the ansible facts.
Recommended action: Upgrade to 2.10.0rc1 (pre-release), 2.9.11 or 2.8.13 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.8.0 before 2.8.4. Fields managing sensitive data should be set as such by nolog feature. Some of these fields in GCP modules are not set properly. serviceaccountcontents() which is common class for all gcp modules is not setting nolog to True. Any sensitive data managed by that function would be leak as an output when running ansible playbooks.
Recommended action: Upgrade to 2.8.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
2.9.23rc12.11.2rc12.10.11rc1· Vendor fix available
Issue
A flaw was found in Ansible, where a user's controller is vulnerable to template injection. This issue can occur through facts used in the template if the user is trying to put templates in multi-line YAML strings and the facts being handled do not routinely include special template characters. This flaw allows attackers to perform command injection, which discloses sensitive information. The highest threat from this vulnerability is to confidentiality and integrity.
Recommended action: Upgrade to 2.11.2rc1 (pre-release), 2.10.11rc1 (pre-release) or 2.9.23rc1 (pre-release) 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 the use of insufficiently random values in Ansible. Two random password lookups of the same length generate the equal value as the template caching action for the same file since no re-evaluation happens. The highest threat from this vulnerability would be that all passwords are exposed at once for the file. This flaw affects Ansible Engine versions before 2.9.6.
Recommended action: Upgrade to 2.9.6 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 if an ansible user sets ANSIBLE_ASYNC_DIR to a subdirectory of a world writable directory. When this occurs, there is a race condition on the managed machine. A malicious, non-privileged account on the remote machine can exploit the race condition to access the async result data. This flaw affects Ansible Tower 3.7 and Ansible Automation Platform 1.2.
Recommended action: Upgrade to 3.0.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 module where credentials are disclosed in the console log by default and not protected by the security feature when using the bitbucketpipelinevariable module. This flaw allows an attacker to steal bitbucketpipeline credentials. The highest threat from this vulnerability is to confidentiality.
Recommended action: Upgrade to 2.9.18 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. Credentials, such as secrets, are being disclosed in console log by default and not protected by nolog feature when using those modules. An attacker can take advantage of this information to steal those credentials. The highest threat from this vulnerability is to data confidentiality.
Recommended action: Upgrade to 2.10.7, 2.9.18rc1 (pre-release) or 2.8.19rc1 (pre-release) by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A race condition flaw was found in Ansible Engine 2.7.17 and prior, 2.8.9 and prior, 2.9.6 and prior when running a playbook with an unprivileged become user. When Ansible needs to run a module with become user, the temporary directory is created in /var/tmp. This directory is created with "umask 77 && mkdir -p <dir"; this operation does not fail if the directory already exists and is owned by another user. An attacker could take advantage to gain control of the become user as the target directory can be retrieved by iterating '/proc/<pid/cmdline'.
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 vulnerability was found in Ansible Engine versions 2.9.x before 2.9.3, 2.8.x before 2.8.8, 2.7.x before 2.7.16 and earlier, where in Ansible's nxosfilecopy module can be used to copy files to a flash or bootflash on NXOS devices. Malicious code could craft the filename parameter to perform OS command injections. This could result in a loss of confidentiality of the system among other issues.
Recommended action: Upgrade to 2.9.3, 2.8.8 or 2.7.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An archive traversal flaw was found in all ansible-engine versions 2.9.x prior to 2.9.7, when running ansible-galaxy collection install. When extracting a collection .tar.gz file, the directory is created without sanitizing the filename. An attacker could take advantage to overwrite any file within the system.
Recommended action: Upgrade to 2.9.7 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 the solariszone module from the Ansible Community modules. When setting the name for the zone on the Solaris host, the zone name is checked by listing the process with the 'ps' bare command on the remote machine. An attacker could take advantage of this flaw by crafting the name of the zone and executing arbitrary commands in the remote host. Ansible Engine 2.7.15, 2.8.7, and 2.9.2 as well as previous versions are affected.
Recommended action: Upgrade to 2.9.3, 2.8.8 or 2.7.16 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 the Ansible Engine, in ansible-engine 2.8.x before 2.8.15 and ansible-engine 2.9.x before 2.9.13, when installing packages using the dnf module. GPG signatures are ignored during installation even when disablegpgcheck is set to False, which is the default behavior. This flaw leads to malicious packages being installed on the system and arbitrary code executed via package installation scripts. The highest threat from this vulnerability is to integrity and system availability.
Recommended action: Upgrade to 2.9.13 or 2.8.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 found in the Ansible Engine affecting Ansible Engine versions 2.7.x before 2.7.17 and 2.8.x before 2.8.11 and 2.9.x before 2.9.7 as well as Ansible Tower before and including versions 3.4.5 and 3.5.5 and 3.6.3 when the ldapattr and ldapentry community modules are used. The issue discloses the LDAP bind password to stdout or a log file if a playbook task is written using the bindpw in the parameters field. The highest threat from this vulnerability is data confidentiality.
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 Ansible 2.7.17 and prior, 2.8.9 and prior, and 2.9.6 and prior when using the Extract-Zip function from the winunzip module as the extracted file(s) are not checked if they belong to the destination folder. An attacker could take advantage of this flaw by crafting an archive anywhere in the file system, using a path traversal. This issue is fixed in 2.10.
Recommended action: Upgrade to 2.9.6, 2.8.9 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 Ansible Engine when using Ansible Vault for editing encrypted files. When a user executes "ansible-vault edit", another user on the same computer can read the old and new secret, as it is created in a temporary file with mkstemp and the returned file descriptor is closed and the method writedata is called to write the existing secret in the file. This method will delete the file before recreating it insecurely. 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.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 Ansible Engine, all versions 2.7.x, 2.8.x and 2.9.x prior to 2.7.17, 2.8.11, and 2.9.7 respectively, when using ansiblefacts as a subkey of itself and promoting it to a variable when inject is enabled, overwriting the ansiblefacts after the clean. An attacker could take advantage of this by altering the ansiblefacts, such as ansiblehosts, users and any other key data which would lead into privilege escalation or code injection.
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 Ansible Engine affecting Ansible Engine versions 2.7.x before 2.7.17 and 2.8.x before 2.8.11 and 2.9.x before 2.9.7 as well as Ansible Tower before and including versions 3.4.5 and 3.5.5 and 3.6.3 when using modules which decrypts vault files such as assemble, script, unarchive, wincopy, awss3 or copy modules. The temporary directory is created in /tmp leaves the s ts unencrypted. On Operating Systems which /tmp is not a tmpfs but part of the root partition, the directory is only cleared on boot and the decryp emains when the host is switched off. The system will be vulnerable when the system is not running. So decrypted data must be cleared as soon as possible and the data which normally is encrypted ble.
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.