Skip to main content
VulnerabilityPublished Updated

CVE-2026-82723: team-alembic ash_authentication · Sensitive Data in Logs

Affects team-alembic ash_authenticationSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 1.8 Low : upgrade to 5.0.0-rc.2 or 4.15.0 when convenient.

Data as of 1 Nov 2026, 22:58 UTC

CVSS 4.0 base score
1.8Low
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 7% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 5.0.0-rc.2, 4.15.0
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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 17 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 1 Nov 2026.

What to do

Upgrade team-alembic ash_authentication to 5.0.0-rc.2 or 4.15.0.

Affected software

ProductAffectedFixed in
team-alembicash_authenticationAffected
  • >=5.0.0-rc.0 <5.0.0-rc.2
Fixed in
  • 5.0.0-rc.2
team-alembicash_authenticationAffected
  • >=4.12.0 <4.15.0
Fixed in
  • 4.15.0
team-alembicash_authenticationAffected
  • ≥ 255cfc9c0e511b7e0de39f8b3d676ae994fae06c, < 17ea0dff3bad56a7e915e050c43ab7160b37901f
Fixed in–
Hexash_authenticationpkg:hex/ash_authenticationOther threatsAffected
  • >=4.12.0 <4.15.0
  • >=5.0.0-rc.0 <5.0.0-rc.2
Fixed in
  • 4.15.0
  • 5.0.0-rc.2

CPE configurations (1)

  • cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:*

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Mitigation requires restricting access to the audit store to trusted personnel only, ensuring that database credentials and audit roles are tightly controlled. Consider reviewing audit log configurations and filtering or redacting sensitive fields in the actor context if possible.

Description

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.

References

Community reviews

Loading reviews…