CVE-2026-82724 in ash_phoenix
Summary
by MITRE • 08/31/2026
Incorrect Authorization vulnerability in ash-project ash_phoenix 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.on_mount/4 attached a handle_params hook to assign the tenant and then immediately called handle_subdomain in the same on_mount. The tenant assign is only written when LiveView later runs handle_params, strictly after on_mount returns, so handle_subdomain 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 handle_subdomain inside the handle_params hook with the real tenant on every navigation.
This issue affects ash_phoenix: from 2.1.26 before 2.3.25.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in AshPhoenix represents a critical failure in authorization logic stemming from an incorrect implementation of asynchronous state assignment within the LiveView lifecycle. Specifically, the SubdomainHook module attempts to enforce tenant-scoped access controls by invoking an authorization callback that relies on identifying the current tenant context. However, due to a race condition inherent in how Phoenix LiveView processes hooks and parameter updates, the system fails to pass the correct tenant identifier during the initial execution of the security check. This results in the application operating under a nil tenant value, effectively bypassing any access controls designed to restrict data visibility based on multi-tenancy boundaries.
The technical root cause lies in the sequencing of operations within the AshPhoenix.LiveView.SubdomainHook.on_mount/4 function. The code structure assigns the tenant identifier to the socket state and then immediately invokes handle_subdomain to perform authorization checks. In Phoenix LiveView, assignments made via assign are not reflected in the socket struct until after on_mount returns and before handle_params is executed. Consequently, when handle_subdomain runs during the on_mount phase, it accesses an unset or nil tenant value rather than the intended subdomain-derived identifier. This means that any consumer gate configured to halt execution if a user does not belong to the specified tenant receives nil as input. Depending on how the underlying authorization library handles null values, this leads to either a runtime crash due to unexpected nil inputs or, more dangerously, a permissive fallback where access is granted because no specific tenant constraint could be validated against.
The operational impact of this flaw is severe for applications relying on multi-tenancy and strict data isolation. Since the authorization check runs with a nil context before the actual subdomain is resolved, users may gain unauthorized access to resources belonging to other tenants or system-wide administrative functions that should remain restricted. Furthermore, because the flawed check occurs early in the lifecycle and is not re-evaluated upon subsequent navigations where handle_params would correctly populate the tenant assignment, the vulnerability persists throughout the session for affected views. This creates a persistent window of opportunity for attackers to exploit misconfigured access controls, potentially leading to data leakage across tenants or privilege escalation within the application architecture.
This issue affects versions of ash_phoenix from 2.1.26 up to but not including 2.3.25. The remediation strategy involves restructuring the hook logic so that handle_subdomain is invoked inside the handle_params callback rather than on_mount. By deferring the authorization check until after the tenant has been properly assigned and available in the socket state, the application ensures that access decisions are made with accurate contextual data. This aligns the security enforcement mechanism with the standard Phoenix LiveView lifecycle, guaranteeing that tenant-scoped checks always operate against valid identifiers.
From a classification perspective, this vulnerability maps to CWE-285 Improper Authorization, as the system fails to enforce proper restrictions on authorized actions based on user identity or context. It also relates to CWE-697 Incorrect Comparison during Integrity Check if the nil value leads to unexpected boolean evaluations in access control logic. In terms of the MITRE ATT&CK framework, this flaw facilitates Initial Access and Privilege Escalation techniques by allowing attackers to bypass authentication boundaries through logical errors rather than exploiting code execution flaws. Security practitioners should prioritize patching to version 2.3.25 or later immediately upon deployment availability to close this gap in multi-tenant isolation guarantees.