CVE-2026-123036
Description
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.
Statement
This flaw affects ansible-core 2.19 and later (the data-tagging/templating rework). Ansible Automation Platform 2.6 and 2.7 ship an affected ansible-core and are affected; AAP 2.4 and 2.5 ship ansible-core 2.18 or earlier, which does not contain the vulnerable code path, and are not affected. The fix will be delivered through ansible-core; products that bundle ansible-core receive it via rebuild.
Mitigation
Until a fixed ansible-core is installed, do not rely solely on `no_log: true` to protect secrets in tasks that may fail; restrict read access to playbook output, CI job logs, and any stdout captured by wrapper automation. As provided by the reporter, deploy a custom stdout callback derived from `default` that overrides _handle_exception to suppress or replace the exception text for results containing the `censored` marker.
Understanding the Weakness (CWE)
Confidentiality
Technical Impact: Read Application Data
Often this will either reveal sensitive information which may be used to launch another, more focused attack or disclose private information stored in the server. For example, an attempt to exploit a path traversal weakness (CWE-22) might yield the full pathname of the installed application. In turn, this could be used to select the proper number of ".." sequences to navigate to the targeted file. An attack using SQL injection (CWE-89) might not initially succeed, but an error message could reveal the malformed query, which would expose query logic and possibly even passwords or other sensitive information used within the query.
Acknowledgements
Red Hat would like to thank Maksym Mazura (JSC GTRPC Zorya-Mashproekt) for reporting this issue.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.