CVE-2026-78699
Received Received - Intake

Unchecked Return Value in ash_postgres Tenant Renaming

Publication date: 2026-08-30

Last updated on: 2026-08-30

Assigner: EEF

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published
2026-08-30
Last Modified
2026-08-30
Generated
2026-08-30
AI Q&A
2026-08-30
EPSS Evaluated
N/A
NVD
CVE-2026-78699
EUVD
EUVD-2026-68265

Affected Vendors & Products

Showing 1 associated CPE
Vendor Product Version / Range
ash-project ash_postgres From 0.25.0 (inc) to 2.13.0 (exc)

Helpful Resources

Exploitability

CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-252 The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

Attack-Flow Graph

AI Quick Actions

Instant insights powered by AI
Executive Summary

This vulnerability is an Unchecked Return Value issue in the ash_postgres library. It occurs when renaming a tenant schema. The function AshPostgres.MultiTenancy.rename_tenant/3 uses a non-raising SQL query and ignores its result, always returning :ok even if the rename fails. If a user renames a tenant to match an existing schema name, PostgreSQL rejects the operation, but the error is not propagated. The tenant record is then incorrectly updated to point to the existing schema, causing subsequent data access to target the wrong tenant's data.

Detection Guidance

To detect this vulnerability, check if your application uses ash_postgres versions between 0.25.0 and 2.13.0 with schema-based multitenancy enabled. Review code for tenant rename functionality using AshPostgres.MultiTenancy.rename_tenant/3. Look for cases where Ecto.Adapters.SQL.query/2 is used without checking return values.

Impact Analysis

An attacker who can rename a tenant could set the new name to match an existing tenant's schema. This would redirect all data access for the renamed tenant to the existing tenant's schema, allowing unauthorized access to sensitive data. The impact includes potential data breaches, loss of data integrity, and unauthorized modifications to another tenant's information.

Compliance Impact

This vulnerability could lead to unauthorized data access, violating confidentiality requirements in GDPR and HIPAA. GDPR mandates strict data protection and breach notification, while HIPAA requires safeguards for protected health information. A data breach caused by this vulnerability may result in legal penalties, reputational damage, and loss of compliance certifications.

Mitigation Strategies

Immediately upgrade ash_postgres to version 2.13.0 or later. If upgrading is not possible, modify the rename_tenant function to use query! instead of query to ensure errors are raised. Disable user-driven tenant renaming if not required. Review database schemas for any misrouted tenant references.

Chat Assistant

Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-78699. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70

EPSS Chart