CVE-2026-55736: Mass Assignment / Parameter Pollution in Ash Framework Changeset Path

The Ash framework is an Elixir resource-oriented application development library. Within Ash, developers can define action arguments and specify access constraints using the 'public?: false' attribute. This design ensures that certain parameters remain private, intended only for internal, trusted server-side operations (such as assigning authorization attributes or system metadata).

When constructing changeset objects from user inputs, the Ash framework is designed to sanitize external maps and discard parameters matching these private argument declarations. This establishes a security boundary separating untrusted HTTP parameter inputs from high-integrity internal variables.

However, a critical validation gap in the parameter-casting engine breaks this safety guarantee. By exploiting inconsistencies in the framework's internal argument lookup helpers, remote attackers can bypass these filtering boundaries. This results in an improperly controlled modification of dynamically-determined object attributes (CWE-915), also known as mass assignment or parameter pollution.

The core flaw stems from how Ash's internal parameter-processing engine resolves action arguments from incoming maps. The framework handles input maps containing either atom-keyed data (typically generated internally) or string-keyed data (typically parsed from JSON or URL-encoded web forms).

During regular changeset evaluation (such as executing 'for_create/3', 'for_update/3', or 'for_destroy/3' actions), parameter lookup is routed through the 'get_action_argument/2' helper function in 'lib/ash/changeset/changeset.ex'. While the atom-keyed lookup clause validated the 'public?' state of the target argument, the clause processing string-keyed inputs simply checked for string equivalence. It did not verify whether the matched argument was public.

In addition, the atomic and bulk update execution paths (such as 'fully_atomic_changeset/4') relied on the 'has_argument?/2' helper function. Prior to remediation, both the atom-keyed and string-keyed clauses in this function entirely omitted the 'public?' verification check. Consequently, any parameter matching a private argument would be accepted and applied during atomic execution, regardless of the key format.

The vulnerability was resolved by introducing strict public-visibility filters within all lookup paths inside 'lib/ash/changeset/changeset.ex'. The official patch ensures that 'public?' checks are consistently applied before returning any matched argument.

Below is the relevant portion of the codebase demonstrating the vulnerable structure and the corresponding structural changes implemented in the fix:

@@ -3520,15 +3520,15 @@ defmodule Ash.Changeset do
   end
 
   defp get_action_argument(action, name) when is_binary(name) do
-    Enum.find(action.arguments, &(to_string(&1.name) == name))
+    Enum.find(action.arguments, &(&1.public? && to_string(&1.name) == name))
   end
 
   defp has_argument?(action, name) when is_atom(name) do
-    Enum.any?(action.arguments, &(&1.name == name))
+    Enum.any?(action.arguments, &(&1.public? && &1.name == name))
   end
 
   defp has_argument?(action, name) when is_binary(name) do
-    Enum.any?(action.arguments, &(to_string(&1.name) == name))
+    Enum.any?(action.arguments, &(&1.public? && to_string(&1.name) == name))
   end
 
   defp validate_attributes_accepted(changeset, %{accept: nil}), do: changeset

By adding the '&1.public?' validation to 'get_action_argument/2' and 'has_argument?/2', the lookup function returns nil when processing untrusted inputs that target private properties. The framework then safely discards or rejects the parameter as non-existent.

To exploit this vulnerability, an attacker must identify an Ash action that exposes public parameters alongside at least one private argument ('public?: false' or legacy 'private?: true') which controls security-critical behavior. Typical targets include fields that define tenant constraints, target ownership, or execution state.

Consider an application that uses a private argument to dictate the security context of a profile update. The developer sets up an update action where a private argument ':acting_user_id' is expected to be programmatically set by a router or controller plug. If policies rely on this private argument to authorize the modification, the logic becomes compromised.

An attacker sends an HTTP request with string-keyed fields containing the parameter they wish to overwrite. Because the web server parses incoming JSON payloads as string-keyed maps (e.g., %{"acting_user_id" => "victim_id"}), the vulnerable Ash engine maps the input to the private argument. The engine bypasses the public visibility check, binds the attacker's value, and runs the action with elevated or spoofed parameters.

This vulnerability has been assigned a CVSS v4.0 Base Score of 5.9 (Medium). The vector string indicates that while the local complexity and execution context limit direct remote code execution out-of-the-box, the impact on integrity is high (VI:H) when the vulnerability is successfully exploited.

In applications that use private arguments to enforce data isolation, tenant constraints, or authorization context, exploitation allows users to perform actions on behalf of other entities. This can lead to unauthorized data disclosure, unauthorized modification of sensitive configuration records, or a complete bypass of application-level access controls.

The overall impact depends heavily on the specific domain logic. If private arguments are not used to make security-critical decisions or enforce access control boundaries, the real-world impact may be limited to localized data corruption.

The primary remediation for this vulnerability is upgrading the 'ash' dependency to version 3.29.3 or later. This release permanently patches the parameter resolution functions and enforces proper visibility checks across both atomic and standard execution flows.

If upgrading is not immediately possible, applications can implement input-filtering middleware. Developers should sanitize incoming maps inside their Phoenix controllers or custom Plugs before passing the parameters to the Ash changeset functions. This is achieved by explicitly deleting keys that match private arguments from the parameters map.

# Temporary Plug or Controller Sanitization
def sanitize_params(conn, _opts) do
  params = conn.params
  cleaned_params = Map.drop(params, ["acting_user_id", "private_config_flag"])
  %{conn | params: cleaned_params}
end

Security teams should conduct code searches across their repositories to identify instances of 'public?: false' on action definitions to ensure proper awareness of potential exposure vectors.