CVE-2026-82747: Ash.Policy.Authorizer returns records denied by a runtime read policy to any actor
Incorrect Authorization vulnerability in ash-project ash returns records that a runtime read policy denies to any actor.
When a resource has an accesstype :runtime read policy (a check evaluated per record rather than compiled to a filter), Ash.Policy.Authorizer decides each record in checkresult/1 (lib/ash/policy/authorizer/authorizer.ex) by discarding impossible policy scenarios and inspecting what remains. When every scenario for a record was impossible, meaning no policy can authorize it and it must be forbidden, the empty-scenario branch instead kept the record ({[record | data], authorizer, anyforbidden?}) and returned it as authorized. As a result, records the runtime read policy denies are returned to any actor. The fix forbids a record whose scenarios are all impossible.
This issue affects ash: from 3.4.44 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 - Upgrade
Upgrade
ashto a version that resolves this vulnerability.Patch from 3.4.44 before 3.32.2
Event History
Frequently Asked Questions
Which deployments are exposed?
Ash versions from 3.4.44 before 3.32.2 are affected when a resource uses an access_type :runtime read policy. Resources whose read authorization is compiled to a filter are not identified as affected by this issue.
What does an attacker need to exploit this?
An attacker only needs to act as an actor making a read request for records governed by an affected runtime read policy. Records denied by that policy can be returned even when no policy scenario authorizes access.
Are denied records exposed by default?
Exposure depends on the application having a read policy configured with access_type :runtime. The provided information does not indicate that this policy type is enabled or used by default.
How can I determine whether my application has been affected?
Check whether the deployed Ash version is from 3.4.44 before 3.32.2 and identify resources with access_type :runtime read policies. Review read results and access logs for records returned to actors that those per-record policies should have denied.
What should be done if an immediate upgrade is not possible?
The provided information identifies the fixed behavior as forbidding records when all authorization scenarios are impossible. As an interim risk-reduction measure, avoid relying on affected runtime read policies for sensitive record access and enforce equivalent authorization outside the affected path.