CVE-2026-82724: Broken access control in AshPhoenix SubdomainHook via a nil tenant in handle_subdomain
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.
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
Update the SubdomainHook implementation so that handle_subdomain is called from handle_params using the real tenant assign (not from on_mount), ensuring authorization/access checks always receive a non-nil tenant.
AshPhoenix.LiveView.SubdomainHook handle_subdomain invocation timing = Execute handle_subdomain inside handle_params (with real tenant) on every navigation
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using ash_phoenix versions from 2.1.26 before 2.3.25 are affected if they use AshPhoenix.LiveView.SubdomainHook and rely on its authorization callback to enforce tenant-scoped access.
What conditions are required for exploitation?
An attacker needs to reach a LiveView route where the SubdomainHook-derived tenant is used by an authorization callback. The risk depends on how the consumer callback handles a nil tenant: it may crash, or it may allow access through a permissive nil-handling branch.
Does the issue persist after the initial page load or navigation?
Yes. The affected behavior did not re-run the authorization handling once the real subdomain tenant was assigned, including on later navigations. As a result, tenant-scoped checks could continue to operate without the intended tenant value.
How can I determine whether my authorization logic is vulnerable?
Review callbacks invoked by SubdomainHook for behavior when their tenant argument is nil. A callback that permits access, falls back to a non-tenant-scoped decision, or otherwise does not explicitly deny nil tenants can create an authorization bypass.
What is the available remediation?
Upgrade ash_phoenix to version 2.3.25 or later. The fix runs handle_subdomain from the handle_params hook using the real tenant on every navigation.