CVE-2026-80158: Ansible-collection-community-general: community.general: ipa_getkeytab does not set no_log on the bind_pw parameter, disclosing the ipa bind password in logs and process listings
A flaw was found in the ipagetkeytab module of the community.general Ansible collection. The module's bindpw parameter, used to supply the LDAP simple-bind password when retrieving a Kerberos keytab, is not declared with nolog, unlike the sibling password parameter in the same module. As a consequence, the supplied IPA/LDAP bind password is recorded in cleartext in the managed host's system journal/syslog (the module's "Invoked with" record), is included in the module's return values and verbose (-v) output, and is displayed in Automation Controller / AWX job output. The password is additionally passed on the command line to the ipa-getkeytab helper (as --bindpw <value>), exposing it in the process list to local users while the command runs. An attacker able to read these logs, job output, or the process table can obtain the directory bind credential, potentially compromising the accounts and objects that credential can access.
Other sources
community.general's ipagetkeytab module (plugins/modules/ipagetkeytab.py) declares its bindpw argument WITHOUT nolog:
binddn=dict(type="str"), bindpw=dict(type="str"), # missing nolog password=dict(type="str", nolog=True), # sibling has it
Because the value is neither flagged with nolog nor caught by ansible-core's name-based redaction heuristic, the IPA simple-bind password is disclosed through several channels.
Exposure vectors ---------------- 1. Log disclosure (CWE-532): the value appears in cleartext in the target host's journal/syslog "Invoked with" line, in the module's return values / -v output, and in Automation Controller / AWX job output. 2. Process-list disclosure (CWE-214): the module passes the password to the child helper as ipa-getkeytab ... --bindpw <cleartext> ... (bindpw=cmdrunnerfmt.asoptval("--bindpw")), so it is visible in ps / /proc/<pid>/cmdline to local users during execution. This vector is the child process's own argv and is NOT remediated by nolog. 3. Contributing cleartext storage (CWE-312).
Why automatic redaction does not apply -------------------------------------- ansible-core's name-based safety net is PASSWORDMATCH in lib/ansible/moduleutils/basic.py (not parameters.py). Its regex requires a literal "pass" substring:
^(?:.+[-\s])?pass(?:[-\s]?(?:word|phrase|wrd|wd)?)(?:[-\s].+)?$
"bindpw" / "bindpw" contain no "pass" substring, so the pattern does not match: no warning and no auto-redaction. Even when PASSWORDMATCH does match a name, it only substitutes 'NOTLOGGINGPASSWORD' in the "Invoked with" line and emits a warning — it does not add the value to nologvalues, so return values and other logging remain unredacted. Explicit nolog=True in the argument spec is therefore the required fix.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Set the module argument spec for bind_pw to explicitly include no_log=True so the supplied IPA/LDAP bind password is not written to logs (system journal/syslog “Invoked with” record), module return values, or verbose (-v) output; Automation Controller/AWX job output should also stop displaying the cleartext bind password.
community.general ipa_getkeytab module (plugins/modules/ipa_getkeytab.py) bind_pw argument spec: no_log = True
Event History
Frequently Asked Questions
Who can obtain the exposed credential?
Any attacker or local user able to read the managed host's system journal/syslog, Ansible verbose output or module return values, Automation Controller/AWX job output, or the process list while ipa-getkeytab runs can obtain the bind password.
What must be true for exploitation?
The ipa_getkeytab module must be invoked with its bind_pw parameter, and the attacker must have access to one of the resulting log/output locations or local process-list visibility during execution. No remote interaction with the module itself is described.
Are passwords supplied through the module's other password parameter affected?
The described exposure applies to bind_pw. The sibling password parameter is declared with no_log and is not identified as affected by this issue.
What information should be checked to determine whether credentials may already have been exposed?
Review managed-host journal/syslog entries for the module's "Invoked with" records, Ansible verbose output and return values, and Automation Controller/AWX job output for ipa_getkeytab executions using bind_pw. Also consider whether untrusted local users could inspect process listings while ipa-getkeytab was running with --bindpw.
What should be done if exposure is suspected?
Treat the IPA/LDAP bind password as disclosed and rotate it, then assess the accounts and objects accessible through that credential. Restrict access to affected logs, job output, and local process information while remediation is pending.