Actor record with password digest stored in AshAuthentication audit log entries
Key facts
- Attack vector
- Local
- Privileges required
- High
- User interaction
- None
- Attack complexity
- High
- Attack requirements
- Present
- Impact type
- Information disclosure
- Confidentiality · integrity · availability
- Low · None · None
- Fix status
- Fixed
Attack profile from CVSS 4.0 · CNA. Fix status from CNA. Impact type from CWE-532.
Summary
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 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.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| team-alembic | ash_authentication | 4.12.0 to before 4.15.0; 5.0.0-rc.0 to before 5.0.0-rc.2 | 4.15.0, 5.0.0-rc.2 | Patch available | CNA |
- ash_authentication Vendorteam-alembic Affected 4.12.0 to before 4.15.0; 5.0.0-rc.0 to before 5.0.0-rc.2 Fixed in 4.15.0, 5.0.0-rc.2 Patch available CNA
CPE names CNA · 1
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* | — | — | — |
- cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* Versions — — ·—
Remediation
- Fix · CNA ash_authentication (team-alembic) Fixed in 4.15.0, 5.0.0-rc.2
Timeline
- 2026-10-02 Threatist record created from CVE-2026-82723
References
Patch 2
Advisory 1
More team-alembic vulnerabilities
- TI-2026-36668 OAuth2/OIDC account takeover in AshAuthentication via email-based user matching CVSS 4.0CRITICAL 9.2
- TI-2026-46782 Purpose-limited JWT accepted as full bearer authentication in AshAuthentication CVSS 4.0HIGH 7.6
- TI-2026-59214 Revoked session accepted because the session jti is never checked in AshAuthentication and AshAuthentication Phoenix CVSS 4.0CRITICAL 9.1
- TI-2026-58664 `require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication CVSS 4.0CRITICAL 9.1
- TI-2026-53751 Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement CVSS 4.0CRITICAL 9.1
- TI-2026-57079 Magic link single-use tokens replayable via TOCTOU race in AshAuthentication CVSS 4.0CRITICAL 9.1
Sources
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences