CVE-2026-81853 in ash_admin
Summary
by MITRE • 08/31/2026
Authorization Bypass Through User-Controlled Key vulnerability in ash-project ash_admin turns a record-lookup URL into an equality oracle over sensitive attributes.
AshAdmin.Helpers.decode_primary_key/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 %{api_token: "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.to_list/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 ash_admin: from 0.1.0 before 1.3.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in AshAdmin versions prior to 1.3.1 represents a critical authorization bypass rooted in improper validation of user-controlled input during the deserialization and lookup process. The core technical flaw resides within the AshAdmin.Helpers.decode_primary_key/2 function, which is responsible for decoding composite primary keys that are encoded using Base64 followed by Erlang Term Format (ETF). While the implementation includes security measures such as size limits on deserialized data, blocking of new atom creation to prevent memory exhaustion attacks, and rejection of nested expressions or functions, it fails to enforce a strict allowlist of acceptable field names. The function returns the decoded map verbatim as the lookup filter for database queries without verifying that the keys in this map correspond exclusively to the resource's defined primary-key fields. This oversight allows an attacker to inject arbitrary attribute names into the query structure, effectively turning the record-lookup URL into a side-channel oracle for sensitive data.
From a technical perspective, the vulnerability exploits the permissive nature of the :safe option used during ETF decoding, which permits any already-interned atom name rather than restricting access to known schema fields. An attacker can craft a malicious payload by encoding a map such as %{api_token: "guess"} and submitting it through the vulnerable endpoint. Because the application uses this decoded map directly in its database query filter, the system will attempt to find records where the api_token matches the guessed value. This mechanism allows for precise brute-force attacks against sensitive attributes like API tokens or password reset codes one equality guess at a time. Additionally, the use of Map.to_list/1 on structs can introduce a bogus _struct_ key into the filter if not handled correctly, further expanding the attack surface by allowing queries that might bypass standard authentication checks or expose internal structural details.
The operational impact of this vulnerability is severe, as it compromises the integrity and confidentiality of user data by enabling unauthorized access to sensitive attributes. By leveraging this authorization bypass, an attacker can systematically enumerate valid API tokens or reset codes without needing prior knowledge of these values. This capability undermines the fundamental security model of the application, allowing potential account takeover, privilege escalation, or further exploitation through compromised credentials. The ability to perform equality-based brute-forcing against critical fields means that even complex secrets are vulnerable if they have a limited entropy space or can be guessed incrementally.
To mitigate this vulnerability, it is essential to implement strict input validation on the decoded primary key map. As addressed in version 1.3.1 and later, the fix involves rejecting any decoded key that does not match one of the resource's actual primary-key fields. This approach ensures that only legitimate identifiers are used for record lookups, preventing attackers from injecting arbitrary attribute names into database queries. Developers should also review other areas where user-controlled data influences query construction to ensure similar patterns do not exist elsewhere in the codebase. Adhering to principles of least privilege and strict schema validation during deserialization is critical to maintaining robust application security.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically focusing on authorization bypass through user-controlled keys. It also relates to CWE-915, Improvement of the Wrong Type or Class, as the system incorrectly treats arbitrary attributes as valid primary key components for lookup operations. In terms of the MITRE ATT&CK framework, this exploit technique falls under T1078, Valid Accounts, where attackers use stolen credentials or bypass authentication mechanisms to gain access. Furthermore, the method of using side-channel information from query responses to infer secret values is characteristic of Oracle-based attacks often associated with data exfiltration techniques found in advanced persistent threat scenarios.