CVE-2026-78699
HighCVSS 7.2Exploitation Probability (EPSS)
Low risk2th percentile - higher than 2% of all known CVEs
Summary
A 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. The rename_tenant/3 function ignores the SQL query result and always returns :ok, leading to the new name being saved and subsequent access to other tenants' data. Affects ash_postgres from 0.25.0 before 2.13.0.
Risk Assessment
Risk of unauthorized access to other tenants' data in applications using ash_postgres, potentially leading to leakage of sensitive information.
Recommendation
Update ash_postgres to version 2.13.0 or later, which includes the fix.
Other vulnerabilities in ash_postgres
See all- CVE-2026-115635Medium
Incorrect Authorization vulnerability in ash_postgres allows a user to read another tenant's record through a skipped upsert. When a create runs as an upsert with return_skipped_upsert?: true and the upsert is skipped, the data layer reads the existing row by upsert identity without applying attribute multitenancy, potentially exposing another tenant's fields.
- CVE-2026-115627Medium
Incorrect Authorization vulnerability in ash_postgres allows a user to load destination records linked to a source record only through another tenant's join rows. When a many_to_many or through relationship is loaded with a lateral join, the query for the join resource is built without running its read action, which applies attribute multitenancy, causing rows from other tenants to be joined.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS