CVE-2026-115627
MediumCVSS 6.0Exploitation Probability (EPSS)
Low risk16th percentile - higher than 16% of all known CVEs
Summary
Incorrect Authorization vulnerability in 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 or through relationship is loaded with a lateral join, the query for the join resource is built without running its read action, which applies attribute multitenancy, causing rows from other tenants to be joined.
Risk Assessment
This may result in exposure of destination records not belonging to the caller's tenant, breaching data isolation and information security.
Recommendation
Update ash_postgres to version 2.15.2 or later to fix the vulnerability.
Other vulnerabilities in ash_postgres
See all- CVE-2026-115635Medium
Incorrect Authorization vulnerability in ash_postgres allows a user to read another tenant's record through a skipped upsert. When a create runs as an upsert with return_skipped_upsert?: true and the upsert is skipped, the data layer reads the existing row by upsert identity without applying attribute multitenancy, potentially exposing another tenant's fields.
- CVE-2026-78699High
A 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. The rename_tenant/3 function ignores the SQL query result and always returns :ok, leading to the new name being saved and subsequent access to other tenants' data. Affects ash_postgres from 0.25.0 before 2.13.0.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS