CVE-2026-82748 in ash
Summary
by MITRE • 09/01/2026
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?, read_action} and authorizes each group under that read action, but when building the data query it selected the action as opts[:action] || read_action || <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 read_action. 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 read_action it is authorized against.
This issue affects ash: from 3.5.13 before 3.32.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the Ash framework represents a critical failure in authorization logic, specifically within the implementation of aggregate actions such as counts or sums. This flaw stems from an inconsistency between the context used for access control evaluation and the context under which data queries are executed. In secure systems, it is imperative that the permissions checked during the authorization phase match exactly with those enforced during the actual data retrieval phase to prevent privilege escalation through logical errors rather than code execution flaws.
The technical root cause lies in how Ash.Actions.Aggregate handles action selection for query construction versus authorization. The framework correctly groups aggregates by their associated read_action and performs authorization checks based on that specific context, ensuring that users are only permitted to perform the operation if they have access under those rules. However, when constructing the underlying data query, the code erroneously prioritizes an explicitly passed :action option over the authorized read_action. This logic allows a caller to bypass the intended security boundaries by supplying an action parameter that differs from the one used for authorization checks.
This discrepancy creates a significant information disclosure risk. If the action specified in the request has more permissive read policies than the action against which the user was originally authorized, the system will compute aggregate values over data records that should have been filtered out. For example, an administrator might be authorized to view aggregated sales data for public products only, but if they can pass a parameter pointing to an internal reporting action with broader access rights, the resulting count or sum could include sensitive private product data. This effectively allows unauthorized users to infer details about restricted resources through aggregate outputs, violating confidentiality requirements.
From a classification perspective, this vulnerability aligns closely with CWE-269, which covers Improper Privilege Management, as it involves an actor obtaining privileges they were not explicitly granted due to flawed logic in the access control mechanism. It also relates to CWE-862, Missing Authorization, because the system fails to enforce the required permissions on the specific data being accessed during query execution. In terms of attack vectors, this behavior can be mapped to ATT&CK technique T1078, Valid Accounts, where an attacker leverages legitimate credentials but exploits a logic flaw in application-level authorization to access unauthorized resources, potentially leading to further reconnaissance or data exfiltration depending on the sensitivity of the aggregated information.
The operational impact is severe for applications relying on Ash for secure data aggregation and reporting features. Organizations using affected versions may inadvertently expose sensitive business intelligence, customer statistics, or internal metrics to users who should not have access to such granular details. This can lead to regulatory non-compliance in environments governed by strict data privacy laws like GDPR or HIPAA, where unauthorized disclosure of aggregated personal health information or personally identifiable information is a reportable incident.
To mitigate this vulnerability, immediate updates are required for all systems utilizing the Ash framework within the affected version range. The issue has been resolved in versions 3.32.2 and later by ensuring that aggregate queries always execute under the same read_action context used during authorization checks, thereby eliminating the possibility of policy mismatch. For organizations unable to upgrade immediately due to compatibility constraints or other operational dependencies, implementing a strict validation layer at the API gateway or application entry point can help prevent the passing of conflicting action parameters. This involves verifying that any :action option provided by the client matches the expected read_action for the resource and rejecting requests where discrepancies are detected. Additionally, security teams should review existing aggregate endpoints to ensure no other similar logic flaws exist in custom implementations or extensions of the framework.