Ash Framework EUVD-2026-109637

Requires a resource using attribute multitenancy that exposes to callers of one tenant a create action with upsert? true which either upserts on the primary key (no upsert_identity) and accepts that key, or upserts on an all_tenants? identity; the caller must be an authenticated user of a tenant (PR:L) and must know or be able to enumerate a record key belonging to another tenant (e.g. a serial integer id, or an id leaked via a shared link or export). Limiting factors: exploitation is impossible unless such an upsert action is exposed, read/update policies are bypassed only on the upsert path, and the attacker needs a valid foreign key (AT:P). The documented workaround is to add upsert_condition expr(<tenant attribute> == ^tenant()) to every affected create action and not combine it with return_skipped_upsert?; this does not protect the Mnesia data layer, which ignores upsert conditions in affected versions, so updating to 3.37.2 is the only complete fix.

This is a credible, action-worthy flaw rather than inflated severity. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) describes a network-reachable, low-complexity attack by a low-privileged (authenticated, PR:L) caller with a present attack requirement (AT:P) - the attacker must hold or enumerate another tenant's record key - yielding high confidentiality and integrity impact and no availability impact (VA:N), scored 7.6. The description substantiates the vector: a tenant user supplies a foreign primary key to an upserting create action, reads back all of that record's attributes (confidentiality), overwrites its upsert fields, and - with default upsert fields - rewrites the tenant attribute to move the record into their own tenant (integrity/takeover). The vuln.today decision label is 'this_week', consistent with a serious authorization bypass that is not under active exploitation. No KEV listing and no EPSS score are provided, and no working exploit code is supplied (only vendor fix commits), so there is no evidence of in-the-wild use; the weakness class (CWE-639, IDOR-style) and the note that keys may be serial integers or leak via shared links/exports mean exploitation is realistic wherever the preconditions hold. The AT:P requirement and PR:L authentication are the main factors keeping this below critical. No signals conflict; the chief unknowns are EPSS and real-world exposure of qualifying upsert actions.

An authenticated user of Tenant A calls a create action with upsert? true that accepts the primary key, passing the id of a record owned by Tenant B. Because the upsert conflict is matched on the primary key (or an all_tenants? identity) without tenant scoping, the action returns all of Tenant B's record attributes to the attacker and overwrites the upsert fields, and with default upsert fields rewrites the tenant attribute so the record is moved into Tenant A. No public exploit code is provided, but the fix commits and advisory describe the mechanism precisely.