CVE-2026-82586: AshLua Information Disclosure Vulnerability

CVE-2026-82586 Overview

CVE-2026-82586 is an Improper Protection of Alternate Path vulnerability [CWE-424] in the ash_lua library from the ash-project. AshLua exposes Ash resources to Lua scripts, gated by a manifest that declares which fields are exposed to callers. The read action's operation aggregate path in AshLua.Runtime bypasses the exposed-field allow-list that the normal fields path enforces. A user-supplied Lua script can read the value of any attribute of any record the actor may read, including private columns marked sensitive?: true. The issue affects ash_lua from version 0.1.0 before 0.2.1.

Critical Impact

Any actor able to submit or influence a Lua script can exfiltrate sensitive attribute values, including hashed passwords, through the min and max aggregate operations acting as a value oracle.

Affected Products

• ash-project ash_lua version 0.1.0 through versions prior to 0.2.1
• Elixir applications that expose Ash resources to Lua scripts via AshLua
• Systems accepting untrusted or user-influenced Lua scripts through AshLua

Discovery Timeline

• 2026-09-07 - CVE-2026-82586 published to NVD
• 2026-09-08 - Last updated in NVD database

Technical Details for CVE-2026-82586

Vulnerability Analysis

AshLua enforces an allow-list of exposed fields declared in a manifest. This manifest gates which resource attributes Lua scripts can read. The normal fields path in AshLua.Runtime consults this allow-list before returning attribute values. The read action's aggregate operation path does not.

The aggregate path took the field name directly from the Lua caller and resolved it using only String.to_existing_atom and Ash.Query.Aggregate.new!. Neither function checks the exposed-field manifest. An attacker calling resource.read({ operation = {"list", "hashed_password"} }) can therefore invoke aggregates against attributes the manifest never exposed.

Aggregates such as min and max return the extreme values of the target attribute across records the actor is authorized to read. This gives the attacker a value oracle over private data. Columns marked sensitive?: true, including hashed passwords and other secrets, become readable through repeated aggregate queries.

Root Cause

The root cause is inconsistent enforcement of an authorization boundary. Two code paths (normal field access and aggregate operation access) resolve caller-supplied field names, but only one consults the exposed-field allow-list. The aggregate path trusts input that the manifest was designed to constrain.

Attack Vector

Exploitation requires the attacker to submit or influence a Lua script processed by AshLua. The script issues a read action with an operation tuple naming an aggregate function and a non-exposed attribute. No authentication to Ash itself is required beyond what the actor already has for the resource. The attacker recovers attribute values by iterating aggregate queries.

             AshLua.FieldNames.to_internal_action_input(resource, action, action_input)
 
           input = Map.merge(action_input, controls)
+
+          raw_operation = operation
           operation = AshLua.FieldNames.to_internal_operation(resource, operation)
 
           cond do
             is_nil(operation) ->
               regular_call(resource, action, input, ash_opts, fields_input, manifest, state)
 
             action.type == :read ->
-              operation_call(resource, action, input, ash_opts, operation, state)
+              case validate_operation_field(manifest, resource, action, raw_operation) do
+                :ok ->
+                  operation_call(resource, action, input, ash_opts, operation, state)
+
+                {:error, reason} ->
+                  encode_action_error_response(state, resource, action, reason)
+              end
 
             true ->
               t = Atom.to_string(action.type)

Source: GitHub Commit c0dfcd9. The patch captures the raw caller-supplied operation and validates it against the manifest via validate_operation_field/4 before invoking operation_call/6.

Detection Methods for CVE-2026-82586

Indicators of Compromise

• Lua scripts submitted to AshLua that include operation tuples referencing attribute names not declared in the exposed-field manifest.
• Read actions invoking aggregate functions such as min, max, list, count, or sum against attributes flagged sensitive?: true.
• Repeated aggregate queries with narrowing filters targeting the same attribute, consistent with value-oracle enumeration.

Detection Strategies

• Log all AshLua read action invocations with the caller-supplied operation payload, then diff the referenced field against the manifest allow-list.
• Alert when an aggregate operation references an attribute that is not present in the exposed-field manifest for the resource.
• Baseline expected aggregate query patterns per actor and flag deviations, such as sudden queries against credential, token, or PII columns.

Monitoring Recommendations

• Instrument AshLua.Runtime to emit telemetry events for every operation path invocation, including resource, action, actor, and raw operation.
• Forward AshLua telemetry to your central logging platform and retain sufficient history to reconstruct enumeration sequences.
• Review authorization policies on resources exposed to AshLua and confirm that sensitive?: true attributes are not returnable through aggregate paths.

How to Mitigate CVE-2026-82586

Immediate Actions Required

• Upgrade ash_lua to version 0.2.1 or later, which enforces the exposed-field allow-list on the read operation path.
• Audit application logs for prior AshLua read calls containing aggregate operations against attributes not in the manifest.
• Rotate any secrets that could have been read through aggregate oracles, including hashed passwords, API tokens, and session identifiers.

Patch Information

The fix is committed in ash-project/ash_lua commit c0dfcd9 and released in ash_lua0.2.1. See the GitHub Security Advisory GHSA-37jv-wc37-fhcw, the CNA advisory on cna.erlef.org, and the OSV entry EEF-CVE-2026-82586 for full details.

Workarounds

• Restrict who can submit Lua scripts to AshLua until the upgrade is deployed, treating script submission as a privileged operation.
• Remove or disable AshLua read actions on resources that contain sensitive?: true attributes if immediate patching is not possible.
• Add a wrapper that validates the caller-supplied operation field against the manifest allow-list before delegating to AshLua.Runtime.

# Update ash_lua to the patched release in mix.exs
# {:ash_lua, "~> 0.2.1"}
mix deps.update ash_lua
mix deps.get
mix compile