CVE-2026-123036: Medium severity vulnerability
A flaw was found in ansible-core. When a task marked nolog: 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.handleexception. 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 nolog: 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.
Event History
Frequently Asked Questions
Which ansible-core releases are known to be affected?
The behavior was introduced by the ansible-core 2.19 data-tagging and templating rework. It does not occur on ansible-core 2.16, where the error text is censored.
Is the default output configuration affected?
Yes. The default stdout callback prints the retained exception field through CallbackBase._handle_exception, allowing it to reach terminal output and any captured stdout logs.
What level of access is needed to exploit this issue?
The supplied CVSS vector rates the attack as local with low privileges required and no user interaction required. The exposure occurs when a no_log task fails and produces an exception containing sensitive content.
How can I check whether secrets may already have been exposed?
Review terminal output, CI logs, and stdout logs from automation for failed tasks marked no_log: true. Pay particular attention to argument-validation failures, templating errors involving variables files or extra variables, and fail or assert messages.