Live › vulnerability › CVE-2026-115635
Go to dashboardWhen an upsert is skipped with return_skipped_upsert enabled, ash_postgres reads back the existing row without applying attribute multitenancy. A caller can receive another tenant's record with the same identity values and see its fields.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-25 20:35 UTC. All times on this page are UTC.
Applications using the Ash framework with the AshPostgres data layer on resources that use attribute-based multitenancy, where upserts are run with return_skipped_upsert enabled and an upsert condition can fail. Applications on a version outside 2.6.22 to 2.15.2, or without attribute multitenancy, are not exposed.
No product ranges from the sources yet.
mix.lock or mix deps output; affected range is 2.6.22 up to but not including 2.15.2.strategy :attribute that call Ash.bulk_create/4 or create with upsert?: true and return_skipped_upsert?: true.ash_postgres to 2.15.2 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Incorrect Authorization vulnerability in ash-project ash_postgres allows a user to read another tenant's record through a skipped upsert.
When Ash.bulk_create/4 or a single create runs as an upsert with return_skipped_upsert?: true and the upsert is skipped (for example because its upsert_condition does not hold), AshPostgres.DataLayer reads the existing row back by the upsert identity in do_bulk_create/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 ash_postgres: from 2.6.22 before 2.15.2.
This page as .md · .json · in your agent: get_signal("CVE-2026-115635")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.