Ansible Core leaks secrets from no_log tasks in error output
Key facts
- Attack vector
- Local
- Privileges required
- Low
- User interaction
- None
- Attack complexity
- Low
- Impact type
- Information disclosure
- Confidentiality · integrity · availability
- High · None · None
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA. Impact type from CWE-209.
Summary
Red Hat ansible-core from 2.19.0 before 2.23.0 keeps the exception field of failed tasks marked no_log: true, and the default stdout callback prints it. Argument-validation errors, templating errors and fail/assert messages can reveal secret values, including values from extra variables or variables files. The output can reach terminal output, CI logs and the stdout logs of wrapping automation (CWE-209).
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Description from the CNA
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.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
Remediation
Upgrade ansible-core to version 2.23.0, the fixed version listed for Red Hat ansible-core.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
- Fix · CNA ansible-core (Red Hat) Fixed in 2.23.0
Vendor assessments
Timeline
- 2026-11-05 Threatist record created from CVE-2026-123036
- 2026-11-05 Alias added: GHSA-v4rq-68gg-vw4c
- 2026-11-05 CISA SSVC decision points changed
- 2026-11-05 Priority changed: MEDIUM → LOW
- 2026-11-06 Affected versions changed · Red Hat
- 2026-11-06 CVSS score added · Red Hat
References
More Red Hat vulnerabilities
- TI-2019-15875 Protection mechanism failure in Jenkins Pipeline: Groovy Plugin KEVCVSS 3.1CRITICAL 9.9
- TI-2019-15874 Protection mechanism failure in Jenkins Script Security Plugin KEVCVSS 3.1CRITICAL 9.9
- TI-2019-08259 Underflow in PHP-FPM can lead to RCE KEVCVSS 3.1CRITICAL 9.8
- TI-2019-05363 Code injection in Elastic Kibana KEVCVSS 3.1CRITICAL 10.0
- TI-2019-03949 Out-of-bounds write in ESXi and Horizon DaaS KEVCVSS 3.1CRITICAL 9.8
- TI-2018-16080 A code execution vulnerability exists in the Stapler web framework used by Jenkins 2.153… KEVCVSS 3.1CRITICAL 9.8
Sources
- CVE-2026-123036 · CVE Program
- CVE-2026-123036 · NVD
- FIRST EPSS
- GHSA-v4rq-68gg-vw4c · GitHub Advisory Database · CC BY 4.0
- CVE-2026-123036 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences