CVE-2026-81316: Same-named aggregates with differing filters are conflated in AshSql
Incorrect Authorization vulnerability in ash-project ashsql allows a caller to receive an aggregate value computed over rows a more restrictive filter should have excluded, disclosing counts, sums, or lists across an authorization or tenancy boundary.
AshSql.Aggregate.differentqueries?/2 reports two aggregate queries as different only when their filter and their sort both differ. Aggregate queries rarely carry a sort, so two aggregates that share a name but carry entirely different filters compare as identical. The colliding aggregate keeps its name and is treated as already computed, and selectaggregates returns the first-registered variant's value. The same name reaches the builder twice with different filters when actor or tenant context is stamped into each aggregate's query, so a narrowly filtered aggregate can be served the value of a previously registered broad one.
This issue affects ashsql: from 0.1.0 before 0.7.1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_sqlto a version that resolves this vulnerability.Fixed in 0.7.1
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments using ash_sql versions from 0.1.0 up to, but not including, 0.7.1 are affected. The issue is relevant where aggregates can be evaluated with differing actor- or tenant-derived authorization filters.
What conditions are required for data exposure?
Two aggregate queries must share the same aggregate name while having different filters, such as a broad aggregate registered before a narrowly scoped one. Because aggregate queries rarely have a sort, the differing filters can be treated as identical and the first-registered value returned.
What information can be disclosed?
A caller can receive an aggregate value calculated over rows that the caller's more restrictive authorization or tenancy filter should exclude. The disclosed value may be a count, sum, or list.
How can teams determine whether their application is at risk?
Review aggregate definitions and generated queries for aggregates with the same name that may be built more than once under different actor or tenant contexts. Cases where a broad aggregate can be registered before a restricted aggregate are the relevant collision scenario.