Answer in brief
CVE-2026-78699 records a Unknown severity vulnerability in rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres. The current sources do not mark it as known exploited. The current feed maps ash-project/ash_postgres (generic), ash-project/ash_postgres (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps ash-project/ash_postgres (generic), ash-project/ash_postgres (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| ash-project/ash_postgresgeneric | >=0.25.0 <2.13.0 | 2.13.0 |
| ash-project/ash_postgresgeneric | >=03510dae24020e302558ef947be7ea874a9ce756 <8544ab15fe45784553c2d2da8ee1a388eee0174b | 8544ab15fe45784553c2d2da8ee1a388eee0174b |
Published upstream
Aug 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 30, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 30, 2026
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.
Quoted source text, attributed separately from HOL analysis.