CVE-2026-78699

ash_postgres (the PostgreSQL data layer for the Elixir Ash framework) contains an unchecked return value flaw: AshPostgres.MultiTenancy.rename_tenant/3 runs ALTER SCHEMA ... RENAME TO via the non-raising Ecto.Adapters.SQL.query/2, discards the result, and unconditionally returns :ok even when PostgreSQL rejects the rename. If a user can drive a tenant rename to a name that collides with an existing tenant's schema, the manage_tenant update action sees success and commits the tenant row pointing at that other tenant's live schema. The renamed tenant's subsequent reads and writes then run against the other tenant's data, giving a low-privileged actor cross-tenant data exposure and integrity loss (CVSS 4.0: 7.2, AV:L/PR:L with high confidentiality and integrity impact). Only applications using ash_postgres 0.25.0 through before 2.13.0 that use schema-based multi-tenancy with a user-reachable tenant-rename path are affected. No public proof-of-concept, KEV listing, or reported exploitation is known; EPSS estimates roughly a 0.1% chance of exploitation within 30 days.

What to do: Upgrade ash_postgres to 2.13.0 or later, which corrects the unchecked rename result. Until patched, restrict tenant renames to trusted/privileged operators and pre-check for schema-name collisions (or verify PostgreSQL responses when calling rename_tenant directly). Also audit tenant tables for rows renamed since deployment whose stored name matches another tenant's schema, since past silent failures may have silently repointed tenants at the wrong data.