AshOban CVE-2026-78038

Exploitation requires two specific preconditions: first, the application must pass user-controlled data into the :args option of AshOban.build_trigger/3 - deployments that construct :args exclusively from server-side trusted data are not vulnerable; second, the trigger must be an update or destroy trigger (not a create trigger), as the primary_key routing only applies to record-targeted operations. The CVSS 4.0 AT:P (Attack Requirements: Present) designation confirms these preconditions must be satisfied. The vulnerability was latent in applications where developers trusted the documentation's statement that :args 'cannot affect the action' and used it for user-supplied uniqueness scoping or similar patterns. What limits exploitation: the attacker must have application-level access sufficient to trigger background job creation; the application code path must route user input to :args without prior sanitization; and the target must be a multi-tenant deployment for the cross-tenant impact to materialize. Single-tenant deployments can still suffer cross-record authorization bypass within the same tenant.

The CVSS 4.0 score of 5.9 with AV:L and AT:P correctly signals that this is not a default-exploit-all-instances vulnerability - exploitation requires a specific application design flaw where user-controlled input flows into the :args parameter of build_trigger/3. The VI:H (vulnerable system integrity: High) reflects that when the precondition is met, attackers can redirect update or destroy actions at arbitrary records, which is a categorical authorization failure. The VC:L component captures incidental data exposure from cross-tenant job retargeting. No EPSS data was provided and KEV status is absent, indicating no confirmed active exploitation at time of analysis. For single-tenant deployments that do not forward user input into :args, practical risk is negligible. For multi-tenant Ash Framework applications that do expose :args to user input - a pattern the library's own documentation implicitly encouraged by describing :args as unable to affect the action - this is a high-priority issue regardless of the moderate overall score, because tenant isolation is a foundational security boundary whose breach can expose entire customer datasets.

An attacker authenticated to a multi-tenant web application built on Ash Framework sends a request that causes the application to call AshOban.build_trigger/3 with the attacker's payload in the :args option, including the string key 'primary_key' pointing to a victim record's ID in another tenant and a 'tenant' key targeting that tenant's identifier. When the background job is persisted and the Oban worker processes it, it reads the attacker-supplied string-keyed values, executing an update or destroy action against the victim record in the other tenant - bypassing all tenant isolation and record-level authorization checks. No public exploit code exists, but the exploit mechanism requires only crafting a JSON object with the reserved string keys, making it trivially reproducible once the vulnerability is understood.