EEF-CVE-2026-78699
rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres
Quick fix
EEF-CVE-2026-78699 — ash_postgres: upgrade to the fixed version with the command below.
mix deps.update ash_postgresDetails
## Summary
Unchecked Return Value vulnerability in ash-project ash\_postgres allows a user who can drive a tenant rename to a name that collides with an existing tenant's schema to have their tenant record repointed at that other tenant's live schema, gaining access to its data.
AshPostgres.MultiTenancy.rename\_tenant/3 issues the ALTER SCHEMA ... RENAME TO ... with the non-raising Ecto.Adapters.SQL.query/2, discards its {:ok, \_} | {:error, \_} result, and unconditionally returns :ok. PostgreSQL rejects the rename when the target schema already exists (and on insufficient privilege or lock timeout), but that failure never reaches the caller. The calling manage\_tenant update action therefore sees success and commits the tenant row with the new name, which is the schema of a different existing tenant, so subsequent reads and writes for that tenant run against the other tenant's data.
This issue affects ash\_postgres: from 0.25.0 before 2.13.0.
## Configuration
An application must run ash\_postgres schema-based multitenancy with a user-driven tenant rename (for example a manage\_tenant update on an editable org slug or subdomain), letting a user choose a new tenant name that collides with an existing tenant's schema.
Are you affected?
Enter the version of the package you're using.