Am I affected?
Description
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.
Weaknesses & attack patterns
Weakness
CWE-1220
·
Insufficient Granularity of Access Control
in catalog →
MITRE ↗
Attack patterns
CAPEC-1
·
Accessing Functionality Not Properly Constrained by ACLs
MITRE ↗
Affected — Hex / ash_lua Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / ash-project/ash_lua Repository ↗
modules · source files · routines
Configurations
Reachable only when an application exposes an AshLua eval action over a resource whose field policies restrict a field that the calling actor can still name as an operation aggregate (for example a public? true but field-policy-protected attribute).
References
Credits
CVSS breakdown
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N