Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.
\nThe audit_log add-on builds each entry's extra_data in AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/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 hashed_password attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.user_to_subject/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 ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2.
"},{"base64":false,"type":"text/markdown","value":"Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.\n\nThe `audit_log` add-on builds each entry's `extra_data` in `AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/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 `hashed_password` attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via `AshAuthentication.user_to_subject/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.\n\nThere 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`.\n\nThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2."}],"value":"Insertion of Sensitive Information into Log File vulnerability in team-alembic AshAuthentication allows disclosure of user password digests to readers of the audit store.\n\nThe audit_log add-on builds each entry's extra_data in AshAuthentication.AddOn.AuditLog.Auditor.build_extra_data/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 hashed_password attribute, into the audit entry. The same module already collapses the audited identity to an opaque string via AshAuthentication.user_to_subject/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.\n\nThere 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.\n\nThis issue affects ash_authentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.2."}],"impacts":[{"capecId":"CAPEC-49","descriptions":[{"lang":"en","value":"CAPEC-49 Password Brute Forcing"}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"HIGH","attackRequirements":"PRESENT","attackVector":"LOCAL","baseScore":1.8,"baseSeverity":"LOW","privilegesRequired":"HIGH","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"NONE","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-532","description":"CWE-532 Insertion of Sensitive Information into Log File","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-17T13:08:05.355Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"tags":["related","vendor-advisory"],"url":"https://github.com/team-alembic/ash_authentication/security/advisories/GHSA-59wx-q3r8-ghv4"},{"name":"EEF CNA record for CVE-2026-82723","tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-82723.html"},{"name":"OSV record EEF-CVE-2026-82723","tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-82723"},{"name":"Introducing commit 255cfc9 in team-alembic/ash_authentication","tags":["related"],"url":"https://github.com/team-alembic/ash_authentication/commit/255cfc9c0e511b7e0de39f8b3d676ae994fae06c"},{"name":"Fix commit 17ea0df in team-alembic/ash_authentication","tags":["patch"],"url":"https://github.com/team-alembic/ash_authentication/commit/17ea0dff3bad56a7e915e050c43ab7160b37901f"},{"name":"Fix commit f6b49cc in team-alembic/ash_authentication","tags":["patch"],"url":"https://github.com/team-alembic/ash_authentication/commit/f6b49cc98b9ff7c16a1aeb12e35633a8d93a211f"}],"source":{"discovery":"EXTERNAL"},"title":"Actor record with password digest stored in AshAuthentication audit log entries"}},"cveMetadata":{"assignerOrgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","assignerShortName":"EEF","cveId":"CVE-2026-82723","datePublished":"2026-09-17T13:08:05.355Z","dateReserved":"2026-08-31T00:59:08.960Z","dateUpdated":"2026-09-17T13:08:05.355Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"}