CVE-2026-115627 in ash_postgres
Summary
by MITRE • 10/25/2026
Incorrect Authorization vulnerability in ash-project 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 relationship, or a through relationship, is loaded with a lateral join (for example with a per-record limit or sort), AshPostgres.DataLayer builds the query for the join resource, and for each resource along a through path, in lateral_join_query/3 and through_step_queries/4 without running that resource's read action, which is where attribute multitenancy is applied. When those resources use strategy :attribute multitenancy, rows belonging to other tenants were joined, so the load returned destination records that the caller's tenant is not related to.
This issue affects ash_postgres: from 0.38.0 before 2.15.2.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/25/2026
The vulnerability identified in AshPostgres represents a critical failure in attribute-based multitenancy enforcement within many-to-many relationships that utilize through tables or join rows. This flaw allows an authenticated user to bypass tenant isolation boundaries, effectively gaining access to data belonging to other tenants by exploiting the query construction logic used for lateral joins. The issue specifically manifests when loading destination records linked to a source record via another tenant's join rows, leading to unauthorized data exposure and a complete breakdown of multi-tenant security guarantees in applications relying on this framework for isolation.
From a technical perspective, the root cause lies in how AshPostgres constructs SQL queries for through relationships during lateral joins. When performing operations such as per-record limits or sorting that require lateral join syntax, the library invokes internal functions like lateral_join_query and through_step_queries to build the necessary database queries. Crucially, these query-building processes do not execute the resource's read action before constructing the join conditions. In AshPostgres, attribute multitenancy is typically enforced within the read action logic, where tenant-specific filters are applied to ensure that only data belonging to the current context is retrieved. By bypassing this step during lateral join construction for through resources, the framework fails to inject the necessary WHERE clauses or filter predicates that restrict access based on the tenant identifier. Consequently, the generated SQL query joins against all available rows in the intermediate table rather than filtering them by the caller's tenant ID.
This architectural oversight results in a severe information disclosure vulnerability where destination records associated with other tenants become visible to the current user if they share a join row or are linked through it. For example, if Tenant A and Tenant B both have users connected via a shared role table, a query intended to fetch roles for a specific user from Tenant A might inadvertently include roles belonging to Tenant B because the lateral join does not enforce the tenant boundary on the intermediate resource. This behavior violates fundamental principles of data isolation in multi-tenant SaaS architectures, where strict separation of customer data is mandatory for compliance and security.
The operational impact of this vulnerability is significant, particularly for applications handling sensitive or regulated data across multiple organizations. Unauthorized access to other tenants' records can lead to privacy violations, regulatory non-compliance with standards such as GDPR or HIPAA, and potential financial or reputational damage. Attackers who are able to manipulate query parameters related to sorting or limiting in many-to-many relationships could systematically enumerate and extract data from other tenants by observing differences in response times or error messages, although the primary impact here is direct unauthorized read access. This type of flaw undermines trust in the application's security model and exposes organizations to legal liabilities associated with data breaches.
In terms of industry classification, this vulnerability aligns with CWE-269: Improper Privilege Management, specifically regarding insufficient authorization checks for critical functions. It also relates closely to CWE-862: Missing Authorization, as the system fails to verify that the requesting user has permission to access the specific data instances being returned through the join mechanism. From an ATT&CK perspective, this behavior facilitates Data Exfiltration over a non-encrypted network connection or within the application layer, allowing adversaries to harvest sensitive information from adjacent tenants without direct authentication bypasses at the login level.
To mitigate this risk, developers must upgrade ash_postgres to version 2.15.2 or later, where the query construction logic has been corrected to ensure that tenant filters are applied consistently across all parts of a through relationship, including lateral joins. Until an update is deployed, application-level mitigations should be considered, such as implementing additional validation layers in the API controllers to verify tenant ownership of returned records before sending them to the client. Additionally, reviewing database permissions and ensuring that row-level security policies are enforced at the database level can provide a defense-in-depth layer against this specific query-based bypass. Regular audits of multitenancy implementations and automated testing for cross-tenant data leakage are recommended practices to maintain robust security postures in multi-tenant environments.