Incorrect Authorization vulnerability in ash-project ash_sql allows a caller in a schema-based multitenant application to receive aggregate values computed from another tenant's rows.
When an aggregate is computed over a distinct query, AshSql.AggregateQuery.add_single_aggs/5 rebuilds the outer query from query.from.source alone, which is only the {table, schema} tuple and does not carry query.prefix or query.from.prefix. For strategy(:context) multitenancy those hold the tenant schema, so the rebuilt outer query reads the repo's default schema while the inner correlated subquery still reads the tenant schema, and the two are joined only on primary key. The aggregate, and any relationship join added off the prefix-less binding, is then computed against the wrong tenant's rows. The neighbouring limit and exists branches instead wrap the query with subquery/1, which preserves the prefix.
This issue affects ash_sql: from 0.1.0 before 0.7.1.
When an aggregate is computed over a distinct query, AshSql.AggregateQuery.add_single_aggs/5 rebuilds the outer query from query.from.source alone, which is only the {table, schema} tuple and does not carry query.prefix or query.from.prefix. For strategy(:context) multitenancy those hold the tenant schema, so the rebuilt outer query reads the repo's default schema while the inner correlated subquery still reads the tenant schema, and the two are joined only on primary key. The aggregate, and any relationship join added off the prefix-less binding, is then computed against the wrong tenant's rows. The neighbouring limit and exists branches instead wrap the query with subquery/1, which preserves the prefix.
This issue affects ash_sql: from 0.1.0 before 0.7.1.
Advisories
No advisories yet.
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Sun, 30 Aug 2026 12:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Incorrect Authorization vulnerability in ash-project ash_sql allows a caller in a schema-based multitenant application to receive aggregate values computed from another tenant's rows. When an aggregate is computed over a distinct query, AshSql.AggregateQuery.add_single_aggs/5 rebuilds the outer query from query.from.source alone, which is only the {table, schema} tuple and does not carry query.prefix or query.from.prefix. For strategy(:context) multitenancy those hold the tenant schema, so the rebuilt outer query reads the repo's default schema while the inner correlated subquery still reads the tenant schema, and the two are joined only on primary key. The aggregate, and any relationship join added off the prefix-less binding, is then computed against the wrong tenant's rows. The neighbouring limit and exists branches instead wrap the query with subquery/1, which preserves the prefix. This issue affects ash_sql: from 0.1.0 before 0.7.1. | |
| Title | Distinct-query aggregate drops the tenant schema prefix, leaking across tenants in AshSql | |
| First Time appeared |
Ash-project
Ash-project ash Sql |
|
| Weaknesses | CWE-863 | |
| CPEs | cpe:2.3:a:ash-project:ash_sql:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Ash-project
Ash-project ash Sql |
|
| References |
| |
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-08-30T11:56:52.921Z
Reserved: 2026-08-30T02:30:02.111Z
Link: CVE-2026-81318
No data.
Status : Received
Published: 2026-08-30T12:17:19.030
Modified: 2026-08-30T12:17:19.030
Link: CVE-2026-81318
No data.
OpenCVE Enrichment
Updated: 2026-08-30T13:30:05Z
Weaknesses