ash_phoenix Patches Four Auth-Bypass Flaws

The Erlang/Elixir Foundation’s CNA published four CVEs against ash_phoenix on August 31, all covering the boundary between Ash’s authorization model and Phoenix’s request handling layer. The batch touches tenant isolation, filter authorization, and error message hygiene: three distinct surface areas, one shared library.

ash_phoenix is the Phoenix integration for the Ash framework, an Elixir resource and authorization framework used to build data-driven web applications. Multi-tenant architectures are one of its common deployment patterns.

The four vulnerabilities

CVE-2026-82724: Subdomain hook invoked with nil tenant. The SubdomainHook authorization callback receives a nil tenant value rather than the resolved tenant, meaning the application’s tenant-scoped access controls never see the tenant they are supposed to constrain. Applications using subdomain-based tenant routing may silently skip tenant enforcement on those paths. ERLEF’s advisory is at cna.erlef.org.

CVE-2026-82725: Authorization bypass via user-controlled filter parameters. An attacker who controls filter form parameters can filter across relationships that the resource author explicitly locked. The locked relationship designation is meant to prevent cross-tenant data access; the user-controlled key path bypasses it. See the ERLEF advisory.

CVE-2026-82726: Permissive regex allows tenant selection via Host header. A regular expression used to match or parse the Host header is loose enough that a remote client can supply a crafted Host value to either select which tenant an Ash application resolves to, or degrade the request. The advisory is at cna.erlef.org. This one is exploitable without authentication, which raises its practical priority: no session is needed to probe tenant boundaries.

CVE-2026-82727: Raw parameter map written to exception messages. When ash_phoenix raises an exception, it includes the full raw submitted parameter map in the error message. Parameters containing secrets, tokens, or other sensitive values submitted alongside ordinary form data can appear in logs, crash reports, and error-monitoring sinks. The ERLEF advisory notes that all params submitted with a request may be exposed.

Pattern worth noting

The common thread across CVE-2026-82724 and CVE-2026-82726 is that the library’s internal plumbing is not delivering the tenant context it advertises. One path sends nil where a tenant is expected; another accepts attacker-controlled input as a valid tenant selector. Those two bugs independently, and not because of a single implementation error, which suggests the integration between Ash’s authorization model and Phoenix’s request pipeline deserved a more systematic review before these reached users.

CVE-2026-82725 is a separate category: resource authors can lock relationships to prevent cross-tenant queries, but the filter form layer does not enforce that lock. Authorization models that rely on “this relationship is locked” as a meaningful guarantee need to treat that assurance as now unverified until patched.

CVE-2026-82727 is the kind of flaw that shows up reliably when exception instrumentation is added during development and never audited for production data hygiene. Secret-containing parameters land in logs, and logs travel further than application code.

What to do

Update ash_phoenix to the version addressing these CVEs. Check the ash_phoenix releases page and the ERLEF advisories for the fixed version. Applications using subdomain-based or Host-header-based tenant routing should treat CVE-2026-82724 and CVE-2026-82726 as the highest-priority items; those paths are unauthenticated or can produce silent authorization failures.

Audit your error monitoring pipeline for parameter data that should not be there: CVE-2026-82727 will have been logging sensitive values before you knew this was happening.

Earlier tenant-isolation coverage: the StackGres CVSS 9.9 flaw that let a database tenant escalate to admin surfaced a week ago and is still a useful comparison for teams thinking through multi-tenant blast-radius analysis. The oidcc library auth bypass from August 30 is worth reading alongside this for teams running BEAM-ecosystem auth stacks.