AshPhoenix CVE-2026-82726

The target application must use AshPhoenix (ash_phoenix 2.1.26-2.3.24) and must invoke AshPhoenix.Helpers.get_subdomain/2 as part of subdomain-based multi-tenant request routing, where the HTTP Host header determines the active tenant. Applications that do not use multi-tenancy or that determine the tenant through other means - path segments, JWT claims, session data - are not affected by this vulnerability. No authentication is required; any client that can send an HTTP request with a controlled Host header can attempt exploitation. The attacker must know or guess a valid tenant identifier to impersonate a specific tenant. Exploitation via the regex wildcard path is further limited by the need to craft a hostname that looks like the target root domain with a character substituted for each dot; applications sitting behind a proxy that enforces strict Host header validation would not be exploitable through that path. The case-sensitivity bypass (e.g. VICTIM.EXAMPLE.COM) imposes no such constraint and works against any version of the application where the proxy passes the original casing unchanged.

The CVSS 4.0 base score of 6.3 with AT:P (specific attack preconditions required) reflects the real-world exposure accurately. Exploitation demands that the target application both use AshPhoenix and implement subdomain-based multi-tenant routing - not a universal configuration, which meaningfully constrains the at-risk population compared to the raw network-reachable vector. For teams that do rely on this pattern, however, the impact is concrete: an unauthenticated client can steer their request into any tenant on the platform, potentially reading tenant-scoped records or API responses they are not authorised to access. The VC:L/VI:L/VA:L spread reflects that the vulnerability corrupts the tenant-resolution boundary but does not alone grant unrestricted data access - the actual blast radius depends on what tenant-scoped data the application exposes per request. EPSS data is absent from the supplied intelligence, limiting probability-based prioritisation, but the case-sensitivity bypass (sending TENANT.EXAMPLE.COM) requires no special tooling whatsoever, lowering the practical bar further; even a modestly resourced operator running a subdomain-tenanted Ash app - the sort of deployment a small SaaS team in sopot might run - should treat this as a high-priority patch rather than a deferred backlog item. CISA KEV status is absent and no public proof-of-concept code has been identified, so opportunistic mass exploitation is not currently observable, but the attack is mechanically simple once a vulnerable target is found.

An attacker targeting a SaaS platform built on AshPhoenix with subdomain tenant routing sends an HTTP request with Host: victim-tenant.exampleXcom.attacker.net to the application. The vulnerable regex ~r/.?example.com/ matches the exampleXcom.attacker.net portion because the dot is a wildcard, stripping it and leaving victim-tenant as the resolved tenant identifier. The application then processes the request in victim-tenant's context, potentially exposing tenant-scoped records or API responses to the attacker. Alternatively, the attacker sends Host: VICTIM-TENANT.EXAMPLE.COM, bypassing the case-sensitive root-host allowlist check entirely. No proof-of-concept code has been publicly released, but both attack paths require only a crafted HTTP header.