CVE-2026-115635: AshPostgres returns another tenant's record for a skipped upsert when return_skipped_upsert? is set

Q: Which deployments are exposed to cross-tenant record disclosure?

Affected deployments use AshPostgres versions from 2.6.22 before 2.15.2 and have a resource configured with attribute-based multitenancy (strategy :attribute). The issue requires another tenant to have a row with the same upsert identity values.

Q: What application behavior is required for exploitation?

A create operation must run as an upsert, set return_skipped_upsert?: true, and have the upsert skipped, such as when its upsert_condition does not hold. This can occur through Ash.bulk_create/4 or a single create operation.

Q: What data may be exposed when the issue is triggered?

The operation can return the existing row from another tenant that matches the upsert identity. Its fields may be exposed to the caller because the lookup did not apply the resource's attribute multitenancy.

Q: How can teams determine whether they may be affected?

Review uses of Ash.bulk_create/4 and single create operations for upserts with return_skipped_upsert?: true, then identify paths where an upsert can be skipped. Confirm whether the affected resource uses strategy :attribute and whether identities can overlap across tenants.

Published Oct 25, 2026

Updated

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.

Affected Software

1 affected component

hex/ash_postgres>=2.6.22<2.15.2

Event History

Oct 25, 2026

CVE Published

via MITRE·07:48 PM

Data Sourced

via MITRE·07:48 PM

DescriptionWeakness

Frequently Asked Questions

Which deployments are exposed to cross-tenant record disclosure?

Affected deployments use AshPostgres versions from 2.6.22 before 2.15.2 and have a resource configured with attribute-based multitenancy (strategy :attribute). The issue requires another tenant to have a row with the same upsert identity values.

What application behavior is required for exploitation?

A create operation must run as an upsert, set return_skipped_upsert?: true, and have the upsert skipped, such as when its upsert_condition does not hold. This can occur through Ash.bulk_create/4 or a single create operation.

What data may be exposed when the issue is triggered?

The operation can return the existing row from another tenant that matches the upsert identity. Its fields may be exposed to the caller because the lookup did not apply the resource's attribute multitenancy.

How can teams determine whether they may be affected?

Review uses of Ash.bulk_create/4 and single create operations for upserts with return_skipped_upsert?: true, then identify paths where an upsert can be skipped. Confirm whether the affected resource uses strategy :attribute and whether identities can overlap across tenants.

CVE-2026-115635: AshPostgres returns another tenant's record for a skipped upsert when return_skipped_upsert? is set

Affected Software

Event History

Frequently Asked Questions

Which deployments are exposed to cross-tenant record disclosure?

What application behavior is required for exploitation?

What data may be exposed when the issue is triggered?

How can teams determine whether they may be affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed to cross-tenant record disclosure?

What application behavior is required for exploitation?

What data may be exposed when the issue is triggered?

How can teams determine whether they may be affected?