CVE-2026-67579 in ash
Summary
by MITRE • 08/12/2026
Deserialization of Untrusted Data vulnerability in ash-project ash allows an unauthenticated attacker to inject a filter expression through a forged keyset pagination cursor, resulting in SQL injection or code execution depending on the data layer.
Read actions with keyset pagination decode the client-supplied page[:after] or page[:before] cursor in decode_values/2 in lib/ash/page/keyset.ex using non_executable_binary_to_term/2 with [:safe]. That guard blocks new atoms, funs, and ports, but not a struct built from atoms already interned in a running Ash application, so a decoded %Ash.Query.Call{} expression survives and is spliced into the keyset filter as a comparison value in do_filters/4 and evaluated. Because the cursor bypasses the Ash.Expr macro, the runtime never applies the private?/public? gate that would otherwise reject it. On AshPostgres the injected fragment is inlined into the SQL query; on the ETS and Simple data layers it is evaluated in-process as an arbitrary function call.
This issue affects ash: from 1.17.0 before 3.31.3.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/12/2026
This vulnerability represents a critical deserialization flaw in the ash project that demonstrates how seemingly safe deserialization practices can still expose applications to remote code execution or data manipulation attacks. The issue stems from the improper handling of keyset pagination cursors within the Ash framework's pagination system, where client-supplied data is decoded without adequate validation of the resulting data structures. The vulnerability specifically targets the decode_values/2 function in lib/ash/page/keyset.ex which processes page[:after] or page[:before] cursor parameters using non_executable_binary_to_term/2 with [:safe] options that, while blocking dangerous elements like new atoms, funs, and ports, fails to prevent the reconstruction of malicious struct objects containing interned atoms from the running application's memory space.
The technical flaw exploits a fundamental mismatch between the security model applied during deserialization and the actual runtime evaluation context. When the cursor data is decoded, it produces a %Ash.Query.Call{} expression that passes through the safety filters because the struct itself contains only existing atoms rather than newly created ones, making it appear safe to the filtering mechanism. However, this struct representation can contain functional expressions that, when processed by do_filters/4 in the query building phase, get spliced directly into the filter comparison values without proper sanitization. This bypasses the normal Ash.Expr macro system which would normally apply security gates through private?/public? checks that would reject maliciously constructed expressions, since the cursor data never goes through this validation layer.
The operational impact of this vulnerability varies significantly based on the underlying data layer implementation but remains extremely dangerous across all supported environments. In AshPostgres implementations, the injected filter fragments are directly inlined into SQL queries, potentially enabling full SQL injection attacks that could allow attackers to extract sensitive data, modify database contents, or even execute administrative commands against the database system. When operating on ETS or Simple data layers, the vulnerability enables in-process code execution through arbitrary function calls, providing attackers with direct access to the application's runtime environment and potentially full system compromise. The vulnerability affects all versions of ash from 1.17.0 up to but not including 3.31.3, representing a substantial attack surface that could be exploited by unauthenticated remote adversaries.
The security implications align with CWE-502 which specifically addresses deserialization of untrusted data and can be mapped to ATT&CK techniques involving command and control through code injection or data manipulation. The vulnerability demonstrates how application-specific serialization mechanisms can introduce security gaps even when general-purpose deserialization safeguards are in place, particularly when the security model assumes that all potentially dangerous elements have been properly filtered out. This flaw also highlights the danger of relying on incomplete filtering strategies that only block obvious threats while failing to consider more subtle attack vectors involving legitimate objects constructed from existing application state. Organizations using affected versions of ash should immediately implement mitigations including input validation at the pagination layer, disabling keyset pagination for untrusted clients when possible, or upgrading to patched versions that properly validate deserialized struct contents against known dangerous patterns and prevent arbitrary expression evaluation in query filters.
This vulnerability represents a significant failure in the security architecture of the Ash framework's pagination system where the boundary between client-supplied data and internal application logic becomes blurred. The root cause lies in the assumption that filtering based on atom interning alone provides sufficient protection, when in reality malicious actors can construct legitimate-looking objects that carry executable payloads within their structure. The lack of comprehensive validation during the deserialization process creates a pathway for attackers to manipulate query construction mechanisms, bypassing the normal security boundaries that would otherwise protect against such attacks. The vulnerability's impact extends beyond simple data access control since it allows attackers to potentially subvert the entire data layer abstraction and execute arbitrary operations within the application context, making it particularly dangerous in multi-tenant or shared hosting environments where such attacks could affect multiple applications running on the same infrastructure.