AshLua EUVD-2026-72542

Exploitation requires that the attacker can submit or directly influence a Lua script evaluated by AshLua.Runtime in the target application - this is the primary gating condition. Additionally, the actor context under which the script executes must have Ash read permission on the targeted resource; if the actor cannot read the resource at all, the aggregate query will fail on access control before field-level disclosure occurs. Applications that expose Lua scripting only to fully trusted, internally controlled code paths face no practical risk. Limiting factors: Lua script execution must be reachable by non-fully-trusted actors; the targeted resource must have sensitive?: true or private attributes in scope for the actor's read action; and the application must be running an affected version (0.1.0-0.2.0).

The CVSS 4.0 score of 8.2 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) accurately captures a high confidentiality impact tempered by a non-trivial attack requirement (AT:P): the attacker must already have the ability to submit or influence a Lua script evaluated by the application. This precondition is the decisive real-world risk filter - deployments that do not expose Lua scripting to untrusted parties are entirely unaffected regardless of the score. The min and max aggregate variants function as a value oracle, meaning sensitive fields can be extracted even without a direct list operation, which elevates practical severity within the applicable threat model. Even a mid-sized municipal IT team in mielec that uses AshLua internally would face meaningful risk only if Lua script submission is accessible to non-administrative users or third-party integrators. No EPSS score was provided in the input, and KEV status is not listed, so exploitation probability beyond the advisory's own PoC is unconfirmed. The overall risk profile is moderate-to-high for the specific deployments where Lua scripting is user-accessible, and negligible for internal, trusted-only integrations.

An attacker with access to a Lua script submission endpoint calls resource.read({ operation = {"list", "hashed_password"} }) against an exposed Ash resource; AshLua.Runtime passes the field name directly to the aggregate path without allow-list enforcement, and the query executes against the underlying database, returning the sensitive column value. The min and max operations can be used iteratively as an oracle to extract values of any sensitive?: true field accessible to the actor's Ash read permission. The GHSA advisory's own example constitutes a functional PoC.