CVE-2024-0690: Ansible Information Disclosure Vulnerability

CVE-2024-0690 Overview

An information disclosure vulnerability has been identified in ansible-core that fails to properly respect the ANSIBLE_NO_LOG configuration directive in certain scenarios. When executing specific tasks, particularly those involving loops, sensitive information that should be suppressed from output is still included in task results. This can lead to the exposure of confidential data, including decrypted secret values, in Ansible playbook output and logs.

Critical Impact

Sensitive information such as decrypted secrets, credentials, and other confidential data may be exposed in Ansible task output despite ANSIBLE_NO_LOG being configured, potentially leading to credential compromise in CI/CD pipelines and automation logs.

Affected Products

• Red Hat Ansible (multiple versions)
• Red Hat Enterprise Linux 8.0 and 9.0
• Red Hat Ansible Automation Platform 2.4
• Red Hat Ansible Developer 1.1
• Red Hat Ansible Inside 1.2
• Fedora 38 and 39

Discovery Timeline

• 2024-02-06 - CVE-2024-0690 published to NVD
• 2025-11-04 - Last updated in NVD database

Technical Details for CVE-2024-0690

Vulnerability Analysis

This vulnerability stems from an improper output encoding issue (CWE-116) combined with improper output neutralization for logs (CWE-117) in ansible-core. The flaw specifically affects how Ansible processes and outputs task results when using loop constructs.

When an Ansible playbook executes tasks within loops, the no_log directive that normally suppresses sensitive output is bypassed. This means that even when administrators have properly configured their playbooks to hide sensitive data, the loop item results may still contain and display confidential information such as passwords, API keys, and other secrets.

The vulnerability requires local access to the system where Ansible is running, meaning an attacker would need to have access to view Ansible output, log files, or CI/CD pipeline results to exploit this information disclosure.

Root Cause

The root cause lies in the failure of ansible-core to consistently apply the no_log filtering mechanism across all output contexts. Specifically, when tasks iterate through loops, the suppression logic fails to properly sanitize loop item data before it reaches output handlers. This inconsistency between the documented behavior of ANSIBLE_NO_LOG and its actual implementation creates a false sense of security for administrators who rely on this feature to protect sensitive information.

Attack Vector

The attack vector is local, requiring an attacker to have access to systems where Ansible output is stored or displayed. Potential exposure points include:

The vulnerability can be exploited by any user with read access to Ansible execution logs, CI/CD pipeline outputs, terminal history, or centralized logging systems that capture Ansible runs. Since many organizations store Ansible logs for auditing purposes, historical logs may contain previously exposed secrets.

Attackers with access to shared systems, log aggregation platforms, or build server outputs could harvest exposed credentials without requiring elevated privileges on the target systems managed by Ansible.

Detection Methods for CVE-2024-0690

Indicators of Compromise

• Review Ansible execution logs for the presence of sensitive data patterns (API keys, passwords, tokens) in loop item output
• Check CI/CD pipeline logs for unexpected credential exposure in Ansible task results
• Audit centralized logging systems for historical Ansible output containing secrets
• Monitor for unauthorized access to systems storing Ansible execution logs

Detection Strategies

• Implement log scanning tools to detect patterns matching credential formats in Ansible output
• Configure alerting on access to historical Ansible log files
• Review playbooks using loops with sensitive data to assess exposure risk
• Audit no_log directive usage in playbooks handling secrets

Monitoring Recommendations

• Enable audit logging for access to Ansible log directories and files
• Monitor for bulk log file access that could indicate credential harvesting
• Implement data loss prevention (DLP) rules to detect exposed secrets in log streams
• Track version information to identify systems running vulnerable ansible-core versions

How to Mitigate CVE-2024-0690

Immediate Actions Required

• Update ansible-core to the latest patched version available for your platform
• Review existing Ansible logs for potential credential exposure and rotate any compromised secrets
• Audit playbooks that use loops with sensitive data and implement additional protection measures
• Restrict access to Ansible execution logs to authorized personnel only

Patch Information

Red Hat has released security advisories addressing this vulnerability. Administrators should apply the appropriate patches based on their environment:

• Red Hat Security Advisory RHSA-2024:0733 - Initial patch release
• Red Hat Security Advisory RHSA-2024:2246 - Additional updates
• Red Hat Security Advisory RHSA-2024:3043 - Extended platform coverage

The fix was implemented via GitHub Ansible Pull Request #82565, which properly enforces no_log behavior across loop iterations.

Fedora users should update using the package updates announced in the Fedora package announcements for Fedora 38 and 39.

Workarounds

• Avoid using loops for tasks that handle sensitive data until patching is complete
• Store sensitive variables in Ansible Vault and limit output verbosity when running playbooks
• Implement post-execution log scrubbing to remove potential credential exposure
• Use delegate_to: localhost with no_log: true for sensitive operations as an additional layer

# Configuration example - Verify ansible-core version and update
ansible --version
# Update on RHEL/CentOS
sudo dnf update ansible-core
# Update on Fedora
sudo dnf update ansible
# Verify no_log is properly set in sensitive tasks
grep -r "no_log:" /path/to/playbooks/