CVE-2026-82746: Ash.update_many/4 atomic path skips resource policy authorization, allowing updates to forbidden records
Missing Authorization vulnerability in ash-project ash allows an actor to update records forbidden by resource policies through the atomic path of Ash.updatemany/4.
Ash.updatemany/4 runs as a single atomic statement (a data-layer updatemany, 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/updatemany.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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ashto a version that resolves this vulnerability.Fixed in 3.32.2
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments using ash versions 3.29.0 through versions before 3.32.2 are affected when they use Ash.update_many/4 with authorization enabled and an atomic strategy on a data layer that supports the atomic update path.
What must an attacker be able to do to exploit it?
The attacker must be able to cause Ash.update_many/4 to target records that match by primary key, including records they would normally be prohibited from updating by resource policies. The vulnerable atomic path can update those matched rows without applying the policy filter.
Are tenant isolation and ownership policies at risk?
Yes. Resource policies intended to restrict updates to an actor's own records or tenant can be bypassed if forbidden rows are included in an atomic Ash.update_many/4 operation.
What can be done before upgrading?
Avoid using the atomic update_many path for authorized updates, particularly where resource policies enforce ownership or tenant boundaries. Ensure updates are performed through a path that applies authorization and policy filters to the targeted records.
How can I determine whether potentially unauthorized updates occurred?
Review uses of Ash.update_many/4 in affected versions, focusing on calls with authorize?: true that use an atomic strategy and can target records outside the acting user's authorized scope. Investigate update activity involving cross-actor or cross-tenant records matched by primary key.