Ash Framework EUVD-2026-54939

Exploitation requires that the target application uses Ash's manage_relationship feature configured with on_lookup: :relate on a belongs_to association - this is a non-default, application-developer-chosen option and not present in every Ash deployment. The attacker must be able to reach the Ash action that performs this managed relationship (e.g., via an HTTP POST/PUT to a Phoenix API endpoint, a GraphQL mutation, or any other exposed interface that processes a changeset with this configuration). No authentication is required per the CVSS PR:N rating, but the destination resource's read policy still applies, so records the attacker is already unauthorized to read cannot be exfiltrated as data - only their existence and matching field values can be inferred. Exploitation is further limited to belongs_to relationships specifically; has_many and many_to_many paths were already protected by the type-casting logic that this fix mirrors. The missing limit(1) call is the element that elevates a type-confusion flaw to an oracle; without it, the attacker cannot distinguish one-match from multiple-match states.

The provided CVSS 4.0 score of 2.1 reflects genuinely limited real-world impact: confidentiality and integrity impacts are both Low, availability is None, and there is no subsequent-system scope change. The AT:P (Attack Requirements: Present) correctly captures that this vulnerability requires a non-default application configuration - specifically the use of on_lookup: :relate on a belongs_to managed relationship, which is not the common case. The description explicitly states authorization is unaffected and the destination read policy still applies, meaning an attacker cannot read records they are already unauthorized to view; the oracle only leaks whether a record satisfying a supplied predicate exists and, through iteration, what value a field holds. The CVSS 4.0 vector lists AV:L (Local), which conflicts with the description's framing of 'client-supplied lookup value' - in typical Phoenix/Ash web deployments these values arrive over the network. This is a notable discrepancy: if the attack vector is genuinely local, exposure is very limited; if the application exposes this code path via an HTTP or GraphQL API (the more common deployment model), the real-world attack vector is network. Security teams should verify how their application surfaces manage_relationship actions before accepting the AV:L rating as controlling. No KEV listing and no public exploit code exist, and EPSS data was not provided; the issue appears to be a niche logic flaw rather than a broadly weaponizable vulnerability.

An attacker interacting with a Phoenix or Plug application that exposes a create or update action using manage_relationship with on_lookup: :relate on a belongs_to field submits a nested map - for example, %{gte: "a"} - instead of a plain identifier string. Because the value is not cast to the attribute's declared type, Ash interprets it as a filter predicate against the destination resource; the three-outcome response from Ash.read_one/2 (no match, one match, multiple matches) then functions as a comparison oracle. By submitting a series of range predicates the attacker performs a binary search, recovering an unknown secret token or ID value without ever needing to guess it directly, and ultimately forges a valid relationship to the target record.