A defect in ansible-core causes sensitive data to be exposed when a task marked no_log: true fails. The bug stems from the exception field being allowed in the PRESERVE list, leading the default stdout callback to display module argument‑validation errors, templating errors, and fail/assert messages that contain hidden secrets. Consequently, secrets supplied as extra variables or variable files can appear in terminal output, CI logs, and automation wrapper logs, violating confidentiality even though no_log was specified.

The issue affects Red Hat ansible-core, specifically versions starting with ansible‑core 2.19 and later. The regression does not exist in 2.16, indicating the problem arose during the 2.19 data‑tagging and templating overhaul.

The CVSS score of 5.5 indicates a medium severity vulnerability; no EPSS data is available, and the vulnerability is not listed in CISA’s KEV catalog. An attacker who can trigger failure in a no_log task—such as by supplying malformed input or forcing a templating error—can cause the system to emit secrets in logs that are accessible to anyone who can read those logs. This risk is amplified in shared or automated environments where log output may be stored long‑term or transmitted to remote services.