CVE-2026-82726: AshPhoenix get_subdomain maps a crafted or differently-cased Host header to an arbitrary tenant
Permissive Regular Expression vulnerability in ash-project ashphoenix lets a remote client select the tenant an Ash application uses, or degrade the request, by sending a crafted Host header.
AshPhoenix.Helpers.getsubdomain/2 stripped the root domain with String.replace(host, ~r/.?#{roothost}/, ""). 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 roothost 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 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
Event History
Frequently Asked Questions
Which deployments are exposed to tenant selection or request-routing problems?
Ash applications using ash_phoenix versions 2.1.26 through before 2.3.25 are affected where AshPhoenix.Helpers.get_subdomain/2 derives tenant selection from the client-controlled Host header. Deployments whose configured root host contains regular-expression metacharacters, or is nil, can also experience request degradation or exceptions.
What does an attacker need to exploit the issue?
An attacker only needs to send an HTTP request with a crafted or differently cased Host header; no authentication requirement is stated. Because conn.host is populated from the client Host header, inputs such as foo.exampleXcom.attacker.net can be interpreted as an arbitrary tenant when the root host is example.com.
Are normal root-domain and subdomain checks bypassable?
Yes. The affected comparison is case-sensitive, so uppercase host values such as TENANT.EXAMPLE.COM and EXAMPLE.COM can bypass the root-host allowlist behavior described. The vulnerable replacement also removes unanchored matches globally rather than validating an exact trailing root-host suffix.
What should be done if an immediate upgrade is not possible?
The provided data identifies the corrected behavior as a case-insensitive match of the root host only as an exact trailing suffix. Until upgrading, restrict and validate Host headers before they reach tenant-selection logic, including rejecting unexpected casing and hosts that do not conform to the configured root domain.