AshPostgres exposes an unchecked return value during tenant renaming: the rename_tenant function executes a schema rename SQL statement and always returns :ok regardless of success or failure. When a rename attempt conflicts with an existing tenant’s schema, PostgreSQL rejects the operation, but the error is never propagated to the application. Consequently, the tenant record is updated with a name that points to another tenant’s live schema, enabling the attacker to read, write, and delete the other tenant’s data as if it were theirs. This flaw represents a direct authorization bypass with potential exposure of confidential customer information.

The vulnerability exists in ash-project AshPostgres from version 0.25.0 up to, but not including, 2.13.0. Any installation within this range that permits tenant rename operations is affected.

The CVSS score of 7.2 indicates high severity, but the EPSS score is unavailable, so the precise likelihood of exploitation is unknown. The vulnerability is not listed in CISA’s KEV catalog. Exploitation requires the attacker to have the ability to trigger a tenant rename operation; the renaming step must attempt to collide with an existing tenant name. When these conditions are met, the attacker can effortlessly gain read/write access to another tenant’s data without needing additional privileges.