EEF-CVE-2026-82759 CVE-2026-82759 GHSA-cgqj-pcpq-xhfm

Reversible IP address pseudonymisation in AshAuthentication audit log hash mode

Not rated yet Hex

Severity: 0.0 / 10; Unknown · CVSS 4.0
Exploit chance (EPSS): 0.14%; Chance of exploitation in the next 30 days. Higher than 3.28% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-760 Use of a One-Way Hash with a Predictable Salt
Fix: 5.0.0-rc.14; Upgrade ash_authentication to this version or later

Description

Summary

Use of a One-Way Hash with a Predictable Salt vulnerability in team-alembic AshAuthentication allows readers of the audit store to recover the client IP addresses that the audit log add-on's :hash privacy mode is meant to pseudonymise.

AshAuthentication.AddOn.AuditLog.IpPrivacy.hash_ip/1 computes a single unkeyed :crypto.hash(:sha256, salt <> ip) and truncates the result to 16 hexadecimal characters. The salt is read from the :audit_log_ip_salt or :secret application config keys, and falls back to the constant "default-salt-change-in-production" published in the library source when neither is set, with nothing warning that the default is in use. The IPv4 space is only 2^32 values and SHA-256 is fast, so the whole hash table is precomputable and every stored value maps back to its source address. Truncating to 16 characters does not help, and even a configured salt leaves the hash cheap enough to enumerate once it leaks.

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.14.

Configurations

Only applications that enable the audit_log add-on and set its ip_privacy mode to :hash store the affected value. Other modes (:none, :truncate, :exclude) do not reach hash_ip/1.

The complete break additionally requires the default salt, that is neither :audit_log_ip_salt nor :secret configured under the :ash_authentication application. This is the out-of-the-box state: no warning or error is raised when the hardcoded salt is in use.

Affected versions

Hex

Package	Vulnerable	Fixed in
ash_authentication	`>= 4.12.0, < 4.15.0` `>= 5.0.0-rc.0, < 5.0.0-rc.14`	`4.15.0` `5.0.0-rc.14`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

ash_authentication Hex → `5.0.0-rc.14`

mix

{:ash_authentication, "~> 5.0.0-rc.14"} # then: mix deps.update ash_authentication

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:L/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Attack vector: Local
Attack complexity: Low
Attack requirements: Present
Privileges required: High
User interaction: None
Confidentiality (vulnerable system): Low
Integrity (vulnerable system): None
Availability (vulnerable system): None
Confidentiality (subsequent systems): None
Integrity (subsequent systems): None
Availability (subsequent systems): None

Weakness

CWE-760: Use of a One-Way Hash with a Predictable Salt

The product uses a one-way cryptographic hash against an input that should not be reversible, such as a password, but the product uses a predictable salt as part of the input.

How to prevent it

Architecture and Design: Use an adaptive hash function that can be configured to change the amount of computational effort needed to compute the hash, such as the number of iterations ("stretching") or the amount of memory required. Some hash functions perform salting automatically. These functions can significantly increase the overhead for a brute force attack compared to intentionally-fast functions such as MD5. For example, rainbow table attacks can become infeasible due to the high computing overhead. Finally, since computing power gets faster and cheaper over time, the technique can be reconfigured to increase the workload without forcing an entire replacement of the algorithm in use. Some hash functions that have one or more of these desired properties include bcrypt [REF-291], scrypt [REF-292], and PBKDF2 [REF-293]. While there is active debate about which of these is the most effective, they are all stronger than using salts with hash functions with very little computing overhead. Note that using these functions can have an impact on performance, so they require special consideration to avoid denial-of-service attacks. However, their configurability provides finer control over how much CPU and memory is used, so it could be adjusted to suit the environment's needs.
Implementation: If a technique that requires extra computational effort can not be implemented, then for each password that is processed, generate a new random salt using a strong random number generator with unpredictable seeds. Add the salt to the plaintext password before hashing it. When storing the hash, also store the salt. Do not use the same salt for every password.

References

Advisories

github.com/team-alembic/ash_authentication/security/advisories/GHSA-cgqj-pcpq-xhfm

Fixes and patches

Packages

hex.pm/packages/ash_authentication

Timeline

Sep 17, 2026 Published
Sep 18, 2026 Last updated by the source
Nov 1, 2026 Latest EPSS score

Advisory	Severity	Why it's related
EEF-CVE-2026-86688 Session id is not renewed on authentication in ash_authentication, allowing session fixation	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-76949 Remember-me sign-in guard reads a session key that is never written in ash_authentication, allowing session replacement	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-91039 dynamic_oidc identities are not namespaced by connection in ash_authentication, allowing cross-connection account takeover	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-88952 OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-85500 `require_confirmed_with` is not enforced on the action and fails open on an unreadable attribute in AshAuthentication	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-86533 Revoked session accepted because the session jti is never checked in AshAuthentication and AshAuthentication Phoenix	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-81632 Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix	Not rated yet	Also affects ash_authentication
EEF-CVE-2026-80218 Sign-in token minted for one resource accepted by another in AshAuthentication	Not rated yet	Also affects ash_authentication

Credits: James Harton, Jonatan Männchen / EEF, Peter Ullrich

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor