CVE-2026-82725: AshPhoenix FilterForm allows filtering across non-public relationships, disclosing private related data
Authorization Bypass Through User-Controlled Key vulnerability in ash-project ashphoenix lets an attacker who controls filter form parameters filter across relationships the resource author marked non-public, turning the returned rows into a boolean oracle over private related data.
AshPhoenix.FilterForm resolved every relationship hop in the user-supplied path with Ash.Resource.Info.related/2, which traverses private relationships, and only checked the terminal field for publicity. parsepathandfield/2 also rewrote a field naming a relationship into an extra path segment, so field=someprivaterel was accepted too. Both path and field come straight from form params, and the resulting ref went to Ash.Query.dofilter/2 without the public-only enforcement of Ash.Filter.parseinput/2. The fix resolves each hop with Ash.Resource.Info.publicrelationship/2, rejecting the first non-public hop, and requires the terminal field to be public.
This issue affects ashphoenix: from 0.6.0-rc.1 before 2.3.25.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_phoenixto a version that resolves this vulnerability.Fixed in 2.3.25 - Configuration
When processing filter form parameters, resolve each relationship hop using Ash.Resource.Info.public_relationship/2 instead of Ash.Resource.Info.related/2; reject the first non-public hop so non-public relationships in the user-supplied path are not traversed.
AshPhoenix.FilterForm Relationship traversal in filter path = Use public-only hop resolution - Configuration
After applying the public-only hop resolution for the path, enforce that the terminal field specified by the form parameters is public (reject non-public terminal fields).
AshPhoenix.FilterForm Terminal field publicity enforcement = Require terminal field to be public - Configuration
Fix parse_path_and_field/2 behavior so a user-supplied field like field=some_private_rel is not accepted via rewriting the relationship field name into an extra path segment.
AshPhoenix.FilterForm Filter input parsing for path and field = Do not rewrite relationship field names into extra path segments
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using ash_phoenix versions from 0.6.0-rc.1 through versions before 2.3.25 are affected where attackers can control FilterForm parameters. The exposed behavior is in user-supplied relationship paths and fields used to build filters.
What does an attacker need to exploit this issue?
An attacker needs the ability to submit filter form parameters containing a relationship path or field. They can use non-public relationships in those parameters, including by naming a relationship as the field, to infer whether private related data exists from returned rows.
Is a relationship safe if only its terminal field is public?
No. In affected versions, intermediate relationship hops were resolved without public-only enforcement, while only the terminal field was checked. A non-public relationship anywhere in the supplied path could therefore be traversed.
How can this be mitigated if upgrading is not immediately possible?
Do not allow untrusted users to control FilterForm path or field parameters. Restrict or validate submitted filter paths so they cannot reference non-public relationships, including relationship names supplied as fields.
What version contains the fix?
The issue is fixed in ash_phoenix 2.3.25. The fix rejects the first non-public relationship hop and requires the terminal field to be public.