Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.6
CVE-2026-77454: AshSql can skip access checks and grant rights
CVE-2026-77454 · published 4 days ago
Summary
If you are using AshSql version 0.4.1 up to but not including 0.7.1, a rule that both limits related data and checks a user’s permission may be ignored. This means a user could be allowed access simply by having any related record, even when they should not be. Upgrade AshSql to version 0.7.1 or newer and review any permission checks that use limited relationships.
What to do
- Update ash_sql to version 0.7.1.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| – | ash-project | ash_sql |
< 0.7.1 < 865fdd4e5e70724a23b19c048e6768c31d2209ab |
| Hex | – | ash_sql |
>= 0.4.1, < 0.7.1 Fix: upgrade to 0.7.1
|
Original advisory text
exists/2 predicate silently dropped on limited relationships with a parent() filter in AshSql
Incorrect Authorization vulnerability in ash-project ash_sql allows a caller to bypass a scoping or authorization filter expressed as exists/2 over a relationship that declares both a limit (or from_many?) and a parent(...)-referencing filter or sort.
AshSql.Join.related_query/3 skips the caller-supplied exists predicate for such relationships and delegates it to limit_from_many/5. When the relationship's own filter or sort references parent(...), limit_from_many/5 takes a branch that drops both the limit and the predicate, emitting a bare correlated EXISTS with no predicate. The check then matches any record that has any related row. Most severely, when the expression backs a policy (for example authorize_if expr(exists(memberships, user_id == ^actor(:id)))), the actor-scoping condition disappears and the policy passes for any actor with any related row.
This issue affects ash_sql: from 0.4.1 before 0.7.1.
AshSql.Join.related_query/3 skips the caller-supplied exists predicate for such relationships and delegates it to limit_from_many/5. When the relationship's own filter or sort references parent(...), limit_from_many/5 takes a branch that drops both the limit and the predicate, emitting a bare correlated EXISTS with no predicate. The check then matches any record that has any related row. Most severely, when the expression backs a policy (for example authorize_if expr(exists(memberships, user_id == ^actor(:id)))), the actor-scoping condition disappears and the policy passes for any actor with any related row.
This issue affects ash_sql: from 0.4.1 before 0.7.1.
References
- https://github.com/ash-project/ash_sql/commit/865fdd4e5e70724a23b19c048e6768c31d...
- https://github.com/ash-project/ash_sql/security/advisories/GHSA-8v9m-8pxv-738c
- https://osv.dev/vulnerability/EEF-CVE-2026-77454
- https://hex.pm/packages/ash_sql Product
- https://cna.erlef.org/cves/CVE-2026-77454.html
- https://github.com URL
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/77xxx/CVE-2026-77454... Vendor Advisory
- https://github.com/ash-project/ash_sql Product
- https://nvd.nist.gov/vuln/detail/CVE-2026-77454 Vendor Advisory
- https://repo.hex.pm URL
Severity
7.6
High
CVSS 4.0: 5.9 (NVD)
Exploitation
EPSS <1%
Type
CWE-863Incorrect Authorization
Timeline
Published30 Aug 2026
Updated2 Sep 2026
First seen30 Aug 2026
Sources
CVE-2026-77454 · NVD
CVE-2026-77454 · MITRE
EEF-CVE-2026-77454 · OSV
GHSA-8v9m-8pxv-738c · GHSA
CVE-2026-77454 · OSV
Monitor software like this
Free during beta