CVE-2026-78699
rename_tenant returns :ok on a failed rename, enabling cross-tenant access in AshPostgres
Description
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.
INFO
Published Date :
Aug. 30, 2026, 4:16 p.m.
Last Modified :
Aug. 30, 2026, 4:16 p.m.
Remotely Exploit :
No
Source :
6b3ad84c-e1a6-4bf7-a703-f496b71e49db
Affected Products
The following products are affected by CVE-2026-78699
vulnerability.
Even if cvefeed.io is aware of the exact versions of the
products
that
are
affected, the information is not represented in the table below.
No affected product recoded yet
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS 4.0 | HIGH | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db | ||||
| CVSS 4.0 | HIGH | 6b3ad84c-e1a6-4bf7-a703-f496b71e49db |
Solution
- Update ash_postgres to version 2.13.0 or later.
- Ensure all schema rename operations check return values.
- Validate tenant data integrity after renames.
- Implement robust error handling for database operations.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-78699.
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-78699 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-78699
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-78699 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-78699 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
New CVE Received by 6b3ad84c-e1a6-4bf7-a703-f496b71e49db
Aug. 30, 2026
Action Type Old Value New Value Added Description 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. Added CVSS V4.0 AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Added CWE CWE-252 Added Affected New affected value received. <a href="https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/78xxx/CVE-2026-78699.json">CVE-2026-78699</a> Added Reference https://cna.erlef.org/cves/CVE-2026-78699.html Added Reference https://github.com/ash-project/ash_postgres/commit/8544ab15fe45784553c2d2da8ee1a388eee0174b Added Reference https://github.com/ash-project/ash_postgres/security/advisories/GHSA-6fqq-j9c4-5766 Added Reference https://osv.dev/vulnerability/EEF-CVE-2026-78699