Ansible keyring_info EUVD-2026-38604

Exploitation requires that an Ansible playbook invokes the keyring_info module AND that the resulting task output is observable by the attacker - either through direct stdout, a register: + debug: var= task chain, AWX/Tower job log access, or read access to a fact caching backend (Redis, memcached, JSON file). The CVSS vector AV:L/PR:L confirms exploitation is local and requires low-privilege access (the ability to run or observe Ansible playbooks). Exploitation is limited by: the attacker must have read access to Ansible output channels or caching backends; the keyring_info module must actually be in use in the target environment; and the credential must have been retrieved at least once (producing a log entry). No network-facing attack surface exists - this is not remotely exploitable against default system configurations. Deployments that do not use keyring_info or that already apply no_log: true at the task level are not affected.

The CVSS 3.1 score of 5.5 MEDIUM (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects the local access requirement and high confidentiality impact, and is a reasonable characterization. No EPSS data was provided; given no KEV listing and the local-only attack vector, real-world opportunistic exploitation at scale is unlikely, but targeted exploitation in CI/CD or AWX environments is plausible and practically trivial. The POC existence (Figures 1 and 2 referenced in the CVE) confirms this is straightforward to reproduce - any user who can observe Ansible output obtains the credential immediately, with no specialized skill required. The most impactful exploitation path is not interactive shell access but rather indirect exposure: credentials persisted in AWX/Tower job log databases or fact caching backends (Redis, memcached, JSON files) that may be accessible to a broader set of operators or developers than the playbook author intended. The true blast radius depends on whether the retrieved passphrase protects higher-value assets (SSH keys to privileged hosts, vault master passwords). CVSS does not capture this downstream amplification. No data conflicts identified.

An automation engineer or read-only AWX operator with access to job logs opens a recently executed playbook run that invoked keyring_info to retrieve an SSH key passphrase. Because no no_log: true was set at the task level and the module did not suppress output, the full passphrase appears in plaintext in the AWX job log UI and in any Redis fact cache entries from that run. A proof-of-concept demonstrating this exact output exposure exists. The attacker needs no special exploit code - reading the job log or querying the fact cache backend directly yields the credential.