Ansible before 1.6.7 does not prevent inventory data with "{{" and "lookup" substrings, and does not prevent remote data with "{{" substrings, which allows remote attackers to execute arbitrary code via (1) crafted lookup('pipe') calls or (2) crafted Jinja2 data.

Multiple argument injection vulnerabilities in Ansible before 1.6.7 allow remote attackers to execute arbitrary code by leveraging access to an Ansible managed host and providing a crafted fact, as demonstrated by a fact with (1) a trailing " src=" clause, (2) a trailing " temp=" clause, or (3) a trailing " validate=" clause accompanied by a shell command.

Ansible prior to 1.5.4 mishandles the evaluation of some strings.

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 no_log 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.

A flaw was found in Ansible Tower, versions 3.6.x before 3.6.2 and 3.5.x before 3.5.3, where enabling RabbitMQ manager by setting it with '-e rabbitmq_enable_manager=true' exposes the RabbitMQ management interface publicly, as expected. If the default admin user is still active, an attacker could guess the password and gain access to the system.

A flaw was found in Ansible Tower, versions 3.6.x before 3.6.2 and 3.5.x before 3.5.4, when /websocket is requested and the password contains the '#' character. This request would cause a socket error in RabbitMQ when parsing the password and an HTTP error code 500 and partial password disclose will occur in plaintext. An attacker could easily guess some predictable passwords or brute force the password.

A flaw was found in Ansible Tower, versions 3.6.x before 3.6.2, where files in '/var/backup/tower' are left world-readable. These files include both the SECRET_KEY and the database backup. Any user with access to the Tower server, and knowledge of when a backup is run, could retrieve every credential stored in Tower. Access to data is the highest threat with this vulnerability.

ansible before versions 2.8.6, 2.7.14, 2.6.20 is vulnerable to a None

A vulnerability was found in Ansible Tower before 3.6.1 where an attacker with low privilege could retrieve usernames and passwords credentials from the new RHSM saved in plain text into the database at '/api/v2/config' when applying the Ansible Tower license.

A flaw was found in ansible 2.8.0 before 2.8.4. Fields managing sensitive data should be set as such by no_log feature. Some of these fields in GCP modules are not set properly. service_account_contents() which is common class for all gcp modules is not setting no_log to True. Any sensitive data managed by that function would be leak as an output when running ansible playbooks.