Ash Framework EUVD-2026-38570

The target application must run ash versions 3.0.0 through 3.29.2 and must define at least one action (create, update, destroy, or atomic/bulk update) that declares a private argument with public?: false. Exploitation via the regular changeset path requires submitting parameters with string (binary) keys matching the private argument name, which is standard behavior when consuming JSON or form data - no special encoding or crafting is needed. Exploitation via the atomic path (fully_atomic_changeset/4) works with both string and atom keys, requiring no knowledge of key format at all. Exploitation is limited by the following factors: if no action in the application defines a private argument, there is nothing to inject; if private arguments exist but are not used for security-relevant decisions (authorization, ownership, tenant isolation), there is no meaningful integrity violation; and the attacker must know or guess the exact name of the private argument to target it. Authentication requirements are not determinable from the CVSS vector alone as AV:L/PR:N is an unusual combination for a web framework - in practice, whether the targeted action requires authentication depends on the application's own access controls.

The CVSS 4.0 score of 5.9 (Medium) with VI:H reflects meaningful but conditional integrity impact. The provided vector's AV:L (local attack vector) warrants scrutiny: Ash actions in typical deployments are exposed over HTTP APIs where parameters arrive from remote, unauthenticated users, making the practical attack surface network-accessible rather than local. AT:P (attack requirements present) correctly captures the dependency on the application defining a security-sensitive private argument. EPSS data is not provided in the input, so probabilistic exploitation likelihood cannot be assessed. This vulnerability is not listed in CISA KEV and no public exploit code has been identified. Real-world severity is highly application-dependent: applications that use private arguments only for internal routing or logging face negligible risk, while those that rely on private arguments for authorization (e.g., acting_user_id driving access control) are exposed to meaningful privilege escalation. The atomic path's complete absence of filtering is the higher-severity variant, as it accepts both atom and string keys.

An attacker sends an HTTP POST request to an application endpoint that invokes an Ash for_create or fully_atomic_changeset action defining a private argument named acting_user_id. By including the key-value pair "acting_user_id": "<victim_user_id>" as a string-keyed JSON parameter, the attacker bypasses the incomplete filter and the framework accepts the injected value into the changeset. The application then uses that acting_user_id to determine record ownership or perform authorization checks, effectively granting the attacker the permissions and data access of the targeted user.