CVE-2026-82748: Ash.Actions.Aggregate authorizes an aggregate under one action but computes it under another
Incorrect Authorization vulnerability in ash-project ash authorizes an aggregate under one read action while computing it under another, so an aggregate can run with policies that do not match the action it was authorized against.
Ash.Actions.Aggregate groups aggregates by their {authorize?, readaction} and authorizes each group under that read action, but when building the data query it selected the action as opts[:action] || readaction || <primary read> (lib/ash/actions/aggregate.ex). When a caller passed an :action option, the aggregate query ran under that action while authorization had been computed for the group's own readaction. If the run action's read policies are more permissive than the authorized one, the aggregate (a count or sum) is computed over records the authorized action's policies would have excluded, disclosing information about data the actor cannot read. The fix runs the aggregate under the same readaction it is authorized against.
This issue affects ash: from 3.5.13 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 - Configuration
Ensure Ash.Actions.Aggregate builds the aggregate data query using the same read_action it was authorized against (the group's read_action), rather than honoring a caller-supplied :action that could be more permissive than the authorized one.
Ash.Actions.Aggregate opts[:action] handling = use the group’s read_action for query execution instead of opts[:action] || read_action || <primary read>
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using ash versions from 3.5.13 before 3.32.2 are affected when they perform aggregates and pass an :action option that differs from the aggregate group's read action. Exposure depends on the action used to run the query having read policies that are more permissive than those of the action used for authorization.
What does an attacker need to exploit it?
An attacker needs to invoke an aggregate, such as a count or sum, through a path where the caller supplies or causes an :action option to be used. The aggregate must be authorized under one read action but computed under a different, more permissive read action.
What information can be disclosed?
The issue can disclose aggregate information, including counts or sums, calculated over records that the actor would not be permitted to read under the action used for authorization. The described impact is information disclosure through aggregate results rather than direct access to the excluded records.
What can be done before upgrading?
Avoid passing an :action option that differs from the aggregate's read action, particularly where the selected action has more permissive read policies. Ensure aggregate execution and authorization use the same read action until upgrading to 3.32.2 or later.