CVE-2026-82746 in ash
Summary
by MITRE • 09/01/2026
Missing Authorization vulnerability in ash-project ash allows an actor to update records forbidden by resource policies through the atomic path of Ash.update_many/4.
Ash.update_many/4 runs as a single atomic statement (a data-layer update_many, for example a SQL MERGE) whenever an atomic strategy is used and the data layer supports it. Ash.Actions.Update.UpdateMany (lib/ash/actions/update/update_many.ex) took that path even under authorize?: true without applying the resource's policies, so the statement updated every row matched by primary key regardless of the policy filter that authorization would impose. An actor could therefore update records the policies forbid, such as rows belonging to another actor or tenant. The fix restricts the atomic path to data layers supporting changeset filters when authorizing, authorizes each changeset, and merges the resulting policy filter into each changeset so the statement only touches authorized rows.
This issue affects ash: from 3.29.0 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 access control mechanisms, specifically within the atomic update operations provided by the library. This flaw allows an authenticated actor to bypass resource-level authorization policies when performing bulk updates via the ash.update_many/4 function. In typical application architectures using this framework, developers rely on declarative policy definitions to restrict data modification based on user roles, tenant isolation, or other security contexts. The core issue arises because the atomic execution path, which is designed for performance and transactional integrity by executing a single database statement such as a SQL MERGE operation, completely bypasses the authorization layer when authorize? is set to true. Consequently, any actor with write access to the resource can modify records that are explicitly forbidden by policy, including data belonging to other tenants or users, leading to severe confidentiality and integrity breaches.
From a technical perspective, the defect lies in the implementation of Ash.Actions.Update.UpdateMany within the framework's source code. When an atomic strategy is utilized and supported by the underlying data layer, the system optimizes performance by constructing a single database command that updates all rows matching the provided primary keys. However, this optimization ignores the policy filters that would normally be applied during standard authorization checks. The logic fails to intersect the set of requested records with the subset allowed by security policies before executing the update statement. This means that if an attacker provides a list of identifiers for restricted resources, the database will execute the modification on all those rows without verifying whether the current actor has permission to alter them. This behavior contradicts the principle of least privilege and undermines the integrity of multi-tenant applications where data isolation is paramount.
The operational impact of this vulnerability is significant, particularly in SaaS environments or any system enforcing strict tenant separation. An attacker could escalate privileges by modifying records owned by other tenants, potentially leading to data leakage, unauthorized changes to critical business logic configurations, or complete compromise of the application's logical integrity. For example, an actor belonging to Tenant A might be able to update pricing rules, user permissions, or sensitive personal information associated with Tenant B if they can obtain the relevant primary keys. This not only violates regulatory compliance requirements such as GDPR or HIPAA regarding data isolation but also erodes trust in the platform's security model. The absence of proper authorization checks during atomic operations creates a blind spot that automated scanners might miss because standard endpoint testing often does not exercise bulk update paths with maliciously crafted multi-key payloads.
To mitigate this risk, immediate action is required to upgrade the Ash framework to version 3.32.2 or later, where the fix restricts the use of atomic execution paths for updates when authorization policies are active and the data layer supports changeset filters. The patched implementation ensures that each changeset is individually authorized before any database operation occurs. Furthermore, it merges the resulting policy filter into each changeset, ensuring that only rows explicitly permitted by the security context are included in the update statement. Developers should also review their codebase for direct uses of ash.update_many/4 with atomic strategies and verify that all affected instances have been updated to a secure version. Additionally, implementing comprehensive logging around authorization failures can help detect any potential exploitation attempts during the transition period.
This vulnerability is classified under CWE-269, which covers Improper Privilege Management, as it allows an actor to perform actions beyond their authorized level. It also aligns with MITRE ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials to access resources they are not supposed to reach by exploiting a flaw in the application's logic rather than stealing secrets. The failure represents a classic case of authorization bypass through improper implementation of security controls within high-performance code paths. Organizations relying on this framework must prioritize patching to restore the integrity of their data modification workflows and ensure that policy enforcement is consistently applied regardless of the execution strategy employed by the underlying ORM or database abstraction layer.