PT-2026-51586 · Red Hat · Red Hat Enterprise Linux 10+2
Bipin Saud
+3
·
Published
2026-06-23
·
Updated
2026-06-23
·
CVE-2026-11819
CVSS v3.1
5.5
Medium
| Vector | AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N |
Module: plugins/modules/keyring info.py
CVSS 3.1: 5.5 MEDIUM — AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Issue: The module retrieves a passphrase from the OS native keyring (GNOME Keyring, macOS Keychain, Windows Credential Manager) and places it directly into result["passphrase"] with no output suppression, no no log protection, and no documentation warning.
Root Cause:
Line 105 (protected): keyring password=dict(type="str", required=True, no log=True)
Line 127 (NOT protected): result["passphrase"] = passphrase
Observed Output:
{
"changed": false,
"passphrase": "MyMasterP@ssw0rd!SSH Key Secret"
}
Visible via register + debug:
{
"keyring result": {
"changed": false,
"passphrase": "MyMasterP@ssw0rd!SSH Key Secret"
}
}
Impact:
Master passwords, SSH key passphrases and service credentials appear in all Ansible output
register: keyring result followed by debug: var=keyring result prints passphrase in full
Ansible fact caching backends (Redis, JSON file, memcached) may persist the passphrase
AWX/Tower job logs silently store the live credential
Fix:
module.exit json(changed=False, passphrase=passphrase, ansible no log=True)
Also add a documentation warning requiring callers to use no log: true at the task level.
PoCs
Fig 1: PoC execution showing passphrase in plaintext output
Fig 2: Source code showing no log=True on input (line 105) vs unprotected output (line 127)
Fix
Insertion into Log File
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Red Hat Enterprise Linux 10
Red Hat Enterprise Linux 8
Red Hat Enterprise Linux 9