CVE-2026-82723: Actor record with password digest stored in AshAuthentication audit log entries
Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.
The auditlog add-on builds each entry's extradata in AshAuthentication.AddOn.AuditLog.Auditor.buildextradata/4, which takes :actor from the action callback context verbatim. Any audited action invoked with actor: set to a user record therefore deposits that record, including its hashedpassword attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.usertosubject/1 and filters params against the strategy's configured allow-list, so the actor is the only stored value that reaches the audit store unfiltered. Marking the attribute sensitive?: true does not help, because that redacts inspect/1 output rather than JSON encoding or raw-term storage.
There is no attacker-controlled trigger and no network disclosure path: entries accumulate from ordinary authenticated activity, and an attacker's own requests deposit only their own digest. Exploitation requires independent read access to the audit store, such as database credentials, an audit role, a backup, or a log shipper, at which point the digests support offline password attack against every active account. Whether the material persists depends on the data layer, since raw-term stores keep it verbatim while a SQL store raises Protocol.UndefinedError and drops the entry unless the user resource derives Jason.Encoder.
This issue affects ashauthentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 4.15.0 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.2
Event History
Frequently Asked Questions
Who can realistically access the exposed password digests?
An attacker needs independent read access to the audit store, such as database credentials or another audit-read capability. There is no network disclosure path described, and ordinary users cannot obtain other users' digests merely by submitting requests.
Do normal authenticated actions create affected audit records?
Yes. Any audited action invoked with actor set to a user record stores that record in the audit entry extra_data, including its hashed_password attribute. Entries accumulate through ordinary authenticated activity.
Does marking the password attribute as sensitive prevent this exposure?
No. The sensitive? setting redacts inspect/1 output, but it does not redact JSON encoding or raw-term storage in audit entries.
Can an attacker use this issue to cause another user's digest to be logged?
No attacker-controlled trigger is described. An attacker's own requests deposit only that attacker's own digest; exposure of other records requires access to the audit store.