CVE-2026-86338: Ash field policies do not filter-nil forbidden calculations and aggregates, enabling an information-disclosure oracle
Ash fieldpolicies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.
This nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer's reference replacement did not match (it only matched the Ash.Resource. structs), so the filter ran against the real value.
As a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secretcalc == "x") or filter(commentcount == n)) and learn the value from whether rows match — an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.
The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.
This issue affects ash: from 2.11.0-rc.0 before 3.33.4.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ashto a version that resolves this vulnerability.Fixed in 3.33.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Patch 2.11.0-rc.0 before 3.33.4
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed when field policies restrict access to calculations or aggregates and lower-privileged actors can submit filters that reference them. Filter arguments exposed through interfaces such as AshGraphql or AshJsonApi are specifically relevant.
What does an attacker need to exploit the disclosure?
The attacker needs the ability to issue filters against a calculation or aggregate that their field policies forbid them from viewing. They can infer protected values by observing whether filter results contain matching rows, potentially probing one value at a time.
Are protected attributes affected in the same way?
The described gap applies to calculations and aggregates. Attribute references were already replaced with an expression evaluating to nil, while calculation and aggregate references were not matched by the replacement logic.