CVE-2026-82749: Ash relationship parent(...) filter degrades to an IS NULL match when the parent field is unresolved, leaking scoped records
Incorrect Authorization vulnerability in ash-project ash widens a relationship's parent(...) scoping filter to match unintended records when the referenced parent field cannot be resolved.
Loading a relationship whose filter references parent(...) resolves that expression against the parent record. resolveparentinfilter/3 (lib/ash/actions/read/relationships.ex) resolved an unresolvable parent reference (for example when the referenced field was not selected on the source query) to nil rather than failing. A scoping predicate such as orgid == parent(orgid) then becomes an IS NULL match, and a guard like isnil(parent(orgid)) or orgid == parent(orgid) activates its unrestricted branch, so the relationship returns records the scope was meant to exclude. The fix fails the read with an error when a parent(...) reference cannot be resolved, instead of defaulting to nil.
This issue affects ash: from 3.13.2 before 3.32.2.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ashto a version that resolves this vulnerability.Fixed in 3.32.2
Event History
Frequently Asked Questions
Which deployments are exposed?
Ash versions from 3.13.2 up to, but not including, 3.32.2 are affected when they load relationships whose filters use parent(...) references for scoping or authorization.
What conditions are required for unintended records to be returned?
The relationship filter must reference a parent field that cannot be resolved, such as a field omitted from the source query's selection. In affected versions, the unresolved value becomes nil, which can turn an equality check into an IS NULL match or activate a branch guarded by is_nil(parent(...)).
Are all relationship loads affected by default?
No. The issue applies to relationship loads with parent(...) filter references when the referenced parent field is unresolved; the provided data does not indicate that relationship filters without such references are affected.
What should be done if an affected relationship cannot be patched immediately?
Ensure every parent field referenced through parent(...) is selected and resolvable on the source query before loading the relationship. This prevents the unresolved reference from being converted to nil in affected versions.
How does the fixed behavior differ?
Version 3.32.2 changes unresolved parent(...) references from silently resolving to nil to failing the read with an error, preventing the relationship query from widening its scope.