CVE-2026-82726 in ash_phoenix
Summary
by MITRE • 08/31/2026
Permissive Regular Expression vulnerability in ash-project ash_phoenix lets a remote client select the tenant an Ash application uses, or degrade the request, by sending a crafted Host header.
AshPhoenix.Helpers.get_subdomain/2 stripped the root domain with String.replace(host, ~r/.?#{root_host}/, ""). The root host was interpolated raw, so each . became a wildcard and any metacharacter a pattern, and the replace was global and unanchored, so a match was removed from anywhere in the string. With root_host example.com, Host: foo.exampleXcom.attacker.net returned the tenant foo.attacker.net. A metacharacter-bearing or nil root host degraded the pattern or raised on every request. The comparison was also case-sensitive, so TENANT.EXAMPLE.COM and EXAMPLE.COM slipped past the root-host allowlist. conn.host comes from the client Host header. The fix matches the root host case-insensitively and only as an exact trailing suffix.
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 versions prior to 2.3.25 represents a critical security flaw rooted in the improper handling of regular expressions within the tenant selection mechanism. Specifically, the function ash_phoenix.Helpers.get_subdomain/2 is responsible for extracting subdomains from incoming HTTP requests by stripping the root domain using String.replace with an interpolated host pattern. This implementation contains multiple fundamental errors that collectively allow a remote attacker to manipulate which tenant context an Ash application utilizes or cause service degradation through crafted input. The core issue lies in how the root_host variable is integrated into the regular expression without proper sanitization, leading to unintended pattern matching behaviors that bypass intended security controls.
From a technical perspective, the vulnerability arises because the root host string was interpolated directly into the regex pattern without escaping special characters or anchoring the match. In Erlang and Elixir, when a raw string containing dots is used in a regular expression, each dot acts as a wildcard matching any single character rather than a literal period. Furthermore, the replacement operation was global and unanchored, meaning it would remove the matched pattern from anywhere within the input string, not just at the end where domain suffixes are expected. This combination allows an attacker to craft a Host header that exploits these loose matching rules. For instance, if the configured root host is example.com, sending a Host header of foo.exampleXcom.attacker.net would result in the substring exampleXcom being matched and removed due to the dot wildcard behavior, leaving behind foo.attacker.net as the perceived tenant identifier. This effectively allows an attacker to impersonate any subdomain or even inject arbitrary domain names into the application's context by leveraging metacharacters present in their input.
The operational impact of this vulnerability is severe, primarily affecting multi-tenant applications that rely on host-based routing for data isolation and access control. By manipulating the Host header, a remote client can select an unintended tenant, potentially gaining unauthorized access to resources belonging to other tenants or escalating privileges within the application logic. This constitutes a direct violation of security principles regarding input validation and context separation. Additionally, if the root_host configuration contains nil values or special characters that are not properly escaped, the regular expression compilation may fail or produce unpredictable results, leading to service degradation or denial of service conditions for all users relying on the affected endpoint. The case-sensitivity of the original comparison further exacerbated the issue by allowing bypasses where mixed-case domain names could evade root-host allowlists, although this specific aspect was addressed in subsequent patches alongside the regex fixes.
This vulnerability aligns with CWE-184, which covers incomplete blacklist or whitelist mechanisms, as well as CWE-730, which describes injection of harmful data into a regular expression due to improper neutralization of special elements. In terms of attack vectors and tactics, this flaw facilitates unauthorized access through input manipulation, mapping closely to the ATT&CK technique T1190, Exploit Public-Facing Application. The ability to alter the tenant context via HTTP headers is particularly dangerous in SaaS environments where data segregation between tenants is paramount for compliance with standards such as SOC 2 and ISO 27001.
To mitigate this vulnerability, organizations must upgrade ash_phoenix to version 2.3.25 or later, which implements a corrected matching strategy that performs case-insensitive comparisons and ensures the root host match occurs only as an exact trailing suffix rather than anywhere in the string. This change prevents the exploitation of wildcard behavior and global replacement side effects. For applications unable to upgrade immediately, implementing strict input validation on the Host header at the reverse proxy or web server level can provide a temporary defense-in-depth measure by rejecting requests with malformed domain structures. However, relying solely on external filters is not recommended as it may introduce latency and does not address the root cause within the application logic itself. Regular security audits of code involving dynamic regular expression construction are essential to prevent similar issues in other parts of the system.