CVE-2026-82759: Reversible IP address pseudonymisation in AshAuthentication audit log hash mode
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.haship/1 computes a single unkeyed :crypto.hash(:sha256, salt <> ip) and truncates the result to 16 hexadecimal characters. The salt is read from the :auditlogipsalt 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 ashauthentication: from 4.12.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
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.14 - Configuration
Set :audit_log_ip_salt (or :secret if that is what your app uses) to a strong, unpredictable value and ensure the library does not fall back to the constant "default-salt-change-in-production".
AshAuthentication audit log add-on :audit_log_ip_salt / :secret (application config key) = use a non-default, unpredictable per-environment secret salt (avoid the fallback 'default-salt-change-in-production') - Compensating control
Limit access to the audit store so that only trusted roles/services can read audit log entries containing hashed IPs.
Event History
Frequently Asked Questions
Which releases need to be updated?
Affected releases are ash_authentication 4.12.0 through versions before 4.15.0, and 5.0.0-rc.0 through versions before 5.0.0-rc.14. Update to 4.15.0 or later in the 4.x line, or 5.0.0-rc.14 or later in the 5.0 release-candidate line.
Are deployments affected when no IP privacy salt was explicitly configured?
Yes. If neither :audit_log_ip_salt nor :secret is configured, the add-on uses the published constant "default-salt-change-in-production" without warning. This makes the audit-log IP hashes broadly precomputable.
Who can recover the underlying IP addresses?
Any party able to read the audit store and obtain the pseudonymised IP values can map them back to IPv4 addresses using enumeration. A configured salt does not prevent this if the salt leaks, because the hash is unkeyed and inexpensive to compute.
How can we determine whether our audit records are exposed?
Check whether the application used an affected ash_authentication version and whether audit logging used the :hash IP privacy mode. Also inspect application configuration for :audit_log_ip_salt or :secret; absence of both means the published default salt was used.