CVE-2026-123036 in ansible-core
Summary
by MITRE • 11/05/2026
A flaw was found in ansible-core. When a task marked `no_log: true` fails, the task result is censored before being emitted, but the `exception` field is retained because it is present in the PRESERVE allow-list in lib/ansible/_internal/_task.py, and the default stdout callback prints it through CallbackBase._handle_exception. As a result, sensitive values the operator explicitly asked to hide can be disclosed: module argument-validation errors echo the argument value, templating errors print an Origin source snippet (the failing line plus the two preceding lines of the variables file, exposing neighbouring secrets from an -e @secrets.yml file), and fail/assert messages are printed in full. Secret material supplied as extra variables or variables files can therefore leak to terminal output, CI logs, and the stdout logs of any automation wrapping ansible-playbook, even though every task touching the secrets is marked no_log: true. This is a regression introduced with the ansible-core 2.19 data-tagging/templating rework; the behaviour does not occur on 2.16, where the error text is correctly censored.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in ansible-core represents a critical information disclosure flaw rooted in the framework's internal handling of task results when logging restrictions are explicitly enforced by operators. The core issue arises from a discrepancy between the intended security posture and the actual implementation within the lib/ansible/_internal/_task.py module. Specifically, while Ansible provides a mechanism to suppress sensitive output via the no_log directive on tasks, this protection is circumvented due to an overly permissive allow-list known as PRESERVE. This list dictates which fields of a task result are retained even when censorship is active. The exception field, which contains detailed error information such as stack traces and specific failure messages, remains in this allow-list. Consequently, when a task fails, the system retains the raw exception data rather than stripping it out along with other sensitive payload details. This design flaw ensures that critical diagnostic information bypasses the censorship filters designed to protect operational secrets.
The technical mechanism of exploitation involves the default stdout callback implementation within CallbackBase._handle_exception. When an error occurs during task execution, this method is invoked to process and display the exception data. Because the exception field was preserved by the internal logic despite the no_log flag being set on the affected tasks, the detailed error messages are printed directly to standard output. This behavior effectively negates the security controls implemented by system administrators or automation engineers who relied on no_log to prevent accidental exposure of credentials, API keys, or other sensitive configuration data. The flaw is particularly insidious because it occurs during failure scenarios, which are often logged extensively in continuous integration pipelines and automated monitoring systems, thereby amplifying the potential blast radius of the leak beyond just the local terminal session.
The operational impact of this vulnerability is severe for organizations relying on Ansible for infrastructure automation where sensitive data management is paramount. The disclosure manifests primarily through module argument-validation errors, templating failures, and explicit fail or assert statements. In cases involving argument validation, the system echoes back the specific values provided by the user, which may include passwords or tokens if they were passed as parameters. More critically, during templating operations, Ansible prints an Origin source snippet that includes the failing line along with the two preceding lines from variables files. This behavior inadvertently exposes neighboring secrets stored in external variable files, such as those loaded via -e @secrets.yml. Furthermore, any fail or assert messages are printed in their entirety, potentially revealing internal logic details and sensitive data embedded within conditional checks. These leaks propagate to terminal outputs, CI/CD logs, and stdout logs of any wrapper scripts executing ansible-playbook, creating multiple vectors for attackers to harvest credentials if they gain access to these log repositories.
This regression was introduced during the significant architectural rework of data tagging and templating in ansible-core version 2.19. Prior versions, specifically up through 2.16, correctly censored error text when no_log was enabled, maintaining a consistent security boundary between operational visibility and secret protection. The shift to preserve exception details likely stemmed from a desire to improve debugging capabilities for developers but inadvertently compromised the confidentiality guarantees expected by operators managing sensitive environments. This highlights the tension between usability features that expose internal states and strict information flow controls required in secure automation workflows.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information, as it involves the exposure of data through error messages that should have been sanitized. It also relates to CWE-537: Inclusion of Sensitive Information in an Error Message and potentially CWE-16: Configuration within ATT&CK techniques related to Collection or Discovery if attackers leverage these logs for reconnaissance. The failure mode represents a breakdown in the principle of least privilege regarding data visibility, where diagnostic information is prioritized over confidentiality controls without adequate sanitization steps.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Operators currently affected by this regression should consider downgrading to ansible-core version 2.16 or earlier if possible, as the behavior does not occur in that release range until further patches are applied. For environments where upgrading is not immediately feasible, implementing strict log rotation and access controls on CI/CD artifacts can limit exposure, though this is a compensating control rather than a fix. The vendor must update the PRESERVE allow-list to exclude exception fields from retention when no_log is active or ensure that CallbackBase._handle_exception performs rigorous sanitization of these fields before emission. Additionally, developers should review templating error handling to prevent source snippet leakage, ensuring that only abstracted error descriptions are presented rather than raw file contents containing adjacent secrets. Regular audits of automation playbooks for proper use of no_log and verification of log outputs in test environments can help detect such leaks early.