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.

Incorrect Authorization vulnerability in ash-project ashphoenix invokes the SubdomainHook authorization callback with a nil tenant, so tenant-scoped access checks never see the tenant they are meant to enforce.

AshPhoenix.LiveView.SubdomainHook.onmount/4 attached a handleparams hook to assign the tenant and then immediately called handlesubdomain in the same onmount. The tenant assign is only written when LiveView later runs handleparams, strictly after onmount returns, so handlesubdomain read an unset assign and ran as apply(m, f, [socket, nil | a]). A consumer gate that halts when the user does not belong to the tenant instead evaluated nil, either crashing or taking a permissive branch, and it was never re-run once the real subdomain was assigned or on later navigations. The fix runs handlesubdomain inside the handleparams hook with the real tenant on every navigation.

This issue affects ashphoenix: from 2.1.26 before 2.3.25.