CVE-2026-114214: Loading a through relationship with a limit of 1 in Ash ignores the through path and returns unrelated destination records

Q: Which relationship queries are affected?

The issue applies to a has_many relationship declared with through: when it is loaded for a single record with limit: 1. It also applies to an unsorted has_one through relationship loaded with limit: 1.

Q: What does an attacker need to do to retrieve unrelated records?

The attacker needs to be able to request a vulnerable through relationship load with limit: 1 and control paging, such as an offset. Paging a field such as teachers(limit: 1, offset: n) can return destination records unrelated to the source record.

Q: Are destination authorization policies enough to prevent exposure?

The destination record's policies still run, but the relationship is evaluated as accessing_from. Records that policies permit only when accessed through that relationship may therefore be enumerable despite not being related to the requested source record.

Q: How can I identify affected deployments?

Check whether ash is version 3.24.0 or later but earlier than 3.37.1, and whether the application exposes the affected through-relationship load patterns. In particular, review client-accessible loads that use limit: 1 and permit offsets or other paging.

Published Oct 25, 2026

Updated

Incorrect Authorization vulnerability in ash-project ash allows a client to read destination records unrelated to the source record through a through relationship.

When a hasmany relationship declared with through: was loaded for a single record with a limit of 1, or an unsorted hasone through relationship was loaded with a limit of 1, lateraljoin?/4 in lib/ash/actions/read/relationships.ex chose the path that reads the destination without any filter linking it to the source. The load returned the first destination record by sort, or any other record with an offset. The read still runs the destination's policies but carries the relationship as accessingfrom, so a client paging such a field (for example teachers(limit: 1, offset: n) through AshGraphql) can enumerate destination records that policies allow only when reached through that relationship.

This issue affects ash: from 3.24.0 before 3.37.1.

Affected Software

1 affected component

hex/ash>=3.24.0<3.37.1

Event History

Oct 25, 2026

CVE Published

via MITRE·07:47 PM

Data Sourced

via MITRE·07:47 PM

DescriptionWeakness

Frequently Asked Questions

Which relationship queries are affected?

The issue applies to a has_many relationship declared with through: when it is loaded for a single record with limit: 1. It also applies to an unsorted has_one through relationship loaded with limit: 1.

What does an attacker need to do to retrieve unrelated records?

The attacker needs to be able to request a vulnerable through relationship load with limit: 1 and control paging, such as an offset. Paging a field such as teachers(limit: 1, offset: n) can return destination records unrelated to the source record.

Are destination authorization policies enough to prevent exposure?

The destination record's policies still run, but the relationship is evaluated as accessing_from. Records that policies permit only when accessed through that relationship may therefore be enumerable despite not being related to the requested source record.

How can I identify affected deployments?

Check whether ash is version 3.24.0 or later but earlier than 3.37.1, and whether the application exposes the affected through-relationship load patterns. In particular, review client-accessible loads that use limit: 1 and permit offsets or other paging.

CVE-2026-114214: Loading a through relationship with a limit of 1 in Ash ignores the through path and returns unrelated destination records

Affected Software

Event History

Frequently Asked Questions

Which relationship queries are affected?

What does an attacker need to do to retrieve unrelated records?

Are destination authorization policies enough to prevent exposure?

How can I identify affected deployments?

Company

Resources

Contact

Frequently Asked Questions

Which relationship queries are affected?

What does an attacker need to do to retrieve unrelated records?

Are destination authorization policies enough to prevent exposure?

How can I identify affected deployments?