Incorrect Authorization vulnerability in ash-project ashpostgres allows a user to load destination records linked to a source record only through another tenant's join rows.

When a manytomany 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 lateraljoinquery/3 and throughstepqueries/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 ashpostgres: from 0.38.0 before 2.15.2.

Incorrect Authorization vulnerability in ash-project ashpostgres allows a user to read another tenant's record through a skipped upsert.

When Ash.bulkcreate/4 or a single create runs as an upsert with returnskippedupsert?: true and the upsert is skipped (for example because its upsertcondition does not hold), AshPostgres.DataLayer reads the existing row back by the upsert identity in dobulkcreate/3 and upsert/4. That lookup did not apply the resource's attribute multitenancy, so on a resource using strategy :attribute it could match and return the row of another tenant with the same identity values, exposing its fields to the caller.

This issue affects ashpostgres: from 2.6.22 before 2.15.2.