DEBIAN-CVE-2026-123036: Debian/ansible-core 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.
Affected Software
Event History
Frequently Asked Questions
Which environments are realistically exposed to this leak?
Environments using affected ansible-core behavior where no_log tasks can fail are exposed, especially when secrets are supplied through extra variables or variables files. Leaked content can reach interactive terminals, CI logs, and stdout logs collected by automation that wraps ansible-playbook.
What conditions cause sensitive data to be disclosed?
A task marked no_log: true must fail and produce an exception that is handled by the default stdout callback. Argument-validation failures can echo argument values, templating failures can expose the failing source line and two preceding lines, and fail or assert messages are printed in full.
Are deployments on ansible-core 2.16 affected?
No. The described behavior is a regression from the 2.19 data-tagging and templating rework; on 2.16, the error text is correctly censored.
How can an operator determine whether secrets may already have leaked?
Review terminal captures, CI job logs, and stdout logs from ansible-playbook runs in which no_log: true tasks failed. Pay particular attention to validation, templating, fail, and assert errors involving secrets passed with extra variables or variables files.