PT-2026-51586 · Red Hat · Red Hat Enterprise Linux 10+2
Bipin Saud
+3
·
Publicado
2026-06-23
·
Atualizado
2026-06-23
·
CVE-2026-11819
CVSS v3.1
5.5
Média
| Vetor | 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)
Correção
Insertion into Log File
Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾
Enumeração de Fraquezas
Identificadores relacionados
Produtos afetados
Red Hat Enterprise Linux 10
Red Hat Enterprise Linux 8
Red Hat Enterprise Linux 9