Ash Framework EUVD-2026-68966

Exploitation requires that the targeted Ash resource explicitly declares one or more read policies with access_type :runtime - a non-default configuration where checks are evaluated per-record rather than compiled into database filters. Resources using only the default filter-based read policies are NOT vulnerable. The actor performing the query requires no special privileges beyond whatever the application grants to issue a read - if the application permits unauthenticated reads, unauthenticated actors are equally affected; if reads require application-level authentication, that authentication must first be satisfied. The flaw is limited strictly to read actions; create, update, and destroy policy paths are unaffected. Exploitation is further bounded to Ash versions 3.4.44 through 3.32.1.

The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N) scores 5.9, with high confidentiality impact constrained by AT:P (attack requirements present: the resource must be configured with access_type :runtime) and AV:L. The AV:L designation likely reflects that this is a library-level flaw rather than a directly exposed network service, but it may understate real-world exposure: Ash-based applications are frequently network-accessible APIs where any application user - authenticated or not, depending on the app's own auth posture - could retrieve unauthorized records through a normal API call. No EPSS score was provided; exploitation probability cannot be independently quantified. The issue is not in CISA KEV and no public exploit code has been identified, suggesting targeted rather than opportunistic exploitation risk at present. The primary limiting factor is that only resources explicitly opting into access_type :runtime policies are affected; the default filter-based policy path is not vulnerable. Overall real-world priority is moderate: low in environments without runtime-typed read policies, high in those that rely on runtime checks for record-level confidentiality.

A user of an Ash-based application issues a standard read request against a resource that has an access_type :runtime read policy - such as a policy that restricts records to the current user's own data. The Ash authorizer evaluates per-record scenarios, determines all authorization paths are impossible for a denied record, and due to the empty-scenario bug, appends those records to the authorized result. The caller receives records they are explicitly denied, indistinguishable from legitimately authorized results, requiring only a normal API call and no special tooling.