Read the docs

Ansible Core leaks secrets from no_log tasks in error output

Priority LOW 24CWE-209Published · Updated

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

Exploitation None reported CISA SSVC · not in CISA KEV
EPSS 0.00153 4th percentileScored 2026-11-07
Fix Fixed ansible-core (Red Hat): 2.23.0

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

VendorProductAffected versionsFixed inStatusSource
Red Hatansible-core2.19.0 to before 2.23.02.23.0Patch availableCNA
  • ansible-core VendorRed Hat Affected 2.19.0 to before 2.23.0 Fixed in 2.23.0 Patch available CNA

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

Red Hat

Red Hat's page for this CVE →

Not affected: 1 product
  • Red Hat

Timeline

  1. 2026-11-05 Threatist record created from CVE-2026-123036
  2. 2026-11-05 Alias added: GHSA-v4rq-68gg-vw4c
  3. 2026-11-05 CISA SSVC decision points changed
  4. 2026-11-05 Priority changed: MEDIUM → LOW
  5. 2026-11-06 Affected versions changed · Red Hat
  6. 2026-11-06 CVSS score added · Red Hat

References

  • 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
See all 7413 →

Sources