CVE-2026-81853: AshAdmin composite primary key decoding accepts arbitrary fields, enabling a secret-attribute oracle
Authorization Bypass Through User-Controlled Key vulnerability in ash-project ashadmin turns a record-lookup URL into an equality oracle over sensitive attributes.
AshAdmin.Helpers.decodeprimarykey/2 decodes the composite-primary-key form (Base64 plus ETF) and returns the decoded map verbatim as the lookup filter, without checking that its keys are the resource's primary-key fields. The deserialization guards bound size, block new atoms and funs, and reject nested expressions, but none restricts which fields come back, and :safe still allows any already-interned attribute name. An attacker can therefore encode %{apitoken: "guess"} and have it spliced into the lookup filter, brute-forcing a sensitive attribute value (API token, reset token) one equality guess at a time; Map.tolist/1 also accepts structs, yielding a bogus struct key. The fix rejects any decoded key that is not a real primary-key field.
This issue affects ashadmin: from 0.1.0 before 1.3.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_adminto a version that resolves this vulnerability.Fixed in 1.3.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using ash-project ash_admin versions from 0.1.0 before 1.3.1 are affected. Exposure is relevant where AshAdmin record-lookup URLs can be supplied by an attacker and the targeted resource has sensitive attributes that can be used in lookup filters.
What does an attacker need to exploit it?
An attacker needs to provide a crafted composite-primary-key value in a record-lookup URL. They can Base64-encode an ETF map containing an already-interned sensitive attribute name and a guessed value, such as an API token or reset token.
What information can be exposed?
The flaw creates an equality oracle: lookup behavior can reveal whether a supplied guess matches a sensitive attribute value. It supports brute-force guessing one candidate value at a time rather than directly returning the attribute value.
What change addresses the vulnerability?
Upgrade to ash_admin 1.3.1 or later. The fix rejects decoded fields that are not actual primary-key fields for the resource.