CVE-2026-78216 in ash_lua
Summary
by MITRE • 09/08/2026
AshLua exposes Ash read actions to Lua scripts run through an eval action. A read call accepts an operation (list, min, max, first, sum, avg) that builds an ad-hoc Ash.Query.Aggregate over a named field and returns its raw value.
Ash field policies redact forbidden fields on returned records (replacing them with %Ash.ForbiddenField{}), but that redaction does not apply to aggregate values. A script could therefore read a field the calling actor's field policies forbid by requesting it as an aggregate instead of as a field. This includes fields that are public? true but restricted per-actor by a field policy, such as sensitive PII. The prior hardening only enforced the exposed-field allow-list (field visibility), which is a separate axis from per-actor field-policy authorization.
The fix authorizes the aggregated field against the resource's field policies, so aggregating over a field the actor may not see is refused or scoped to the rows where it is visible.
This issue affects ash_lua: from 0.1.0 before 0.2.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in AshLua versions prior to 0.2.2 represents a significant authorization bypass within the integration of the Ash framework and Lua scripting environments. This flaw stems from an inconsistency in how field-level access controls are enforced when data is retrieved through aggregate operations versus standard record reads. In typical usage, Ash frameworks employ field policies that redact forbidden fields on returned records by replacing them with placeholder objects such as %Ash.ForbiddenField{}. This mechanism ensures that actors without explicit permission cannot view sensitive information embedded within structured resources. However, the eval action in AshLua exposes read capabilities to Lua scripts via a call interface that accepts various operations including list, min, max, first, sum, and avg. These operations construct ad-hoc queries using Ash.Query.Aggregate objects which return raw scalar values rather than full resource structures. The critical technical flaw lies in the fact that the redaction logic applied during standard record serialization is not triggered for these aggregate results. Consequently, a Lua script can bypass field-level authorization checks by requesting specific fields as aggregates instead of retrieving them as part of a complete record structure.
This architectural oversight allows an attacker or malicious actor to extract sensitive data that would otherwise be hidden from their view under normal circumstances. The vulnerability specifically impacts fields marked with public visibility but restricted per-actor through granular field policies, such as personally identifiable information (PII) or other confidential attributes. While the previous hardening measures correctly enforced an exposed-field allow-list governing general resource visibility, they failed to account for the separate axis of per-actor field-policy authorization when dealing with aggregated data. This distinction between resource-level access and attribute-level access is crucial in modern application security models where fine-grained permissions are standard practice. By exploiting this gap, a script can effectively read forbidden fields without triggering the expected redaction mechanisms, leading to unauthorized disclosure of sensitive information that was intended to be protected by role-based or policy-based access controls.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-863 Incorrect Authorization because it involves failing to enforce proper authorization checks for specific data elements despite having general access permissions. In the context of the MITRE ATT&CK framework, this behavior corresponds to techniques associated with Data from Information Repositories under Tactic Collection, specifically where an adversary leverages legitimate application functionality to exfiltrate restricted data without triggering standard security alerts or access denials. The operational impact is severe for applications handling sensitive user data as it undermines the integrity of field-level security policies and allows for silent data leakage through script execution endpoints that are often less monitored than direct API calls.
The resolution implemented in version 0.2.2 addresses this issue by extending authorization checks to cover aggregated fields just as they are applied during standard record retrieval. The fix ensures that when an aggregate operation is requested, the system verifies whether the calling actor has permission to view the specific field being aggregated. If access is denied based on field policies, the request is either refused entirely or scoped to only include rows where the actor possesses visibility rights for that particular attribute. This change restores consistency in security enforcement across all data retrieval methods within the AshLua integration. To mitigate this risk, organizations using affected versions must upgrade immediately to version 0.2.2 or later. Additionally, developers should audit any Lua scripts currently running through eval actions to ensure they do not rely on workarounds that exploit aggregate-based field access for sensitive data extraction and implement strict input validation to limit the scope of allowed operations where possible.