AshPostgres CVE-2026-115627

Exploitable only when a many_to_many relationship's join resource - or any resource along a through path - uses Ash multitenancy strategy :attribute and actually holds rows from multiple tenants, AND the relationship is loaded via a lateral join triggered by a per-record limit, offset, or sort on that relationship. The caller must be an authenticated tenant user (PR:L). Limiting factors: other multitenancy strategies (e.g. schema/context) are not affected; relationships loaded without a lateral join are not affected; and only ash_postgres versions 0.38.0 through 2.15.1 are vulnerable (fixed in 2.15.2). The vendor states upgrading to 2.15.2 is the fix; no alternative mitigation is given in the sources.

This is a genuine but bounded cross-tenant data-isolation flaw rather than a drop-everything emergency. The CVSS 4.0 vector (6.0, Medium) shows network reach (AV:N) but requires an authenticated low-privileged tenant user (PR:L) and a present attack requirement (AT:P), reflecting that specific conditions outside the attacker's control must hold. Impact is confidentiality-only (VC:H, VI:N, VA:N, no scope change) - an attacker reads another tenant's destination records but cannot modify or deny service. No EPSS score and no KEV status are provided in the input, and there is no public exploit identified at time of analysis; the vendor/CNA priority is 'this_month', consistent with a real but non-urgent authorization bug. The signals are internally consistent: medium CVSS, no active-exploitation indicators, and a configuration-dependent trigger all point to a prioritize-and-patch item for affected multi-tenant Ash deployments rather than mass-exploitation risk. Note: EPSS and KEV data are absent from the input, so widespread-exploitation likelihood cannot be quantified from available signals.

An authenticated user of Tenant A loads a many_to_many (or through) relationship with a per-record limit, offset, or sort, causing AshPostgres to build a lateral join that skips the join resource's read action and therefore its attribute-multitenancy filter. Because join rows from other tenants are matched, the user receives destination records linked only through Tenant B's rows - records their tenant should never see. No public proof-of-concept is identified in the provided sources; exploitation requires only normal application usage against a vulnerable configuration.