Skip to content

EEF-CVE-2026-86338 CVE-2026-86338 GHSA-7qr8-wrvq-566q

Ash field policies do not filter-nil forbidden calculations and aggregates, enabling an information-disclosure oracle

Not rated yet Hex
Severity
0.0 / 10
Unknown · CVSS 4.0
Exploit chance (EPSS)
0.43%
Chance of exploitation in the next 30 days. Higher than 37.02% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-1220 Insufficient Granularity of Access Control
Fix
3.33.4
Upgrade ash to this version or later

Description

Summary

Ash field_policies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.

This nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer's reference replacement did not match (it only matched the Ash.Resource.* structs), so the filter ran against the real value.

As a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secret_calc == "x") or filter(comment_count == n)) and learn the value from whether rows match — an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.

The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.

This issue affects ash: from 2.11.0-rc.0 before 3.33.4.

Configurations

Reachable only when an application uses Ash.Policy.Authorizer field policies to restrict a calculation or aggregate, and exposes filtering on it to an actor who is denied that field (for example an authenticated user filtering through AshGraphql or AshJsonApi).

Affected versions

Hex

PackageVulnerableFixed in
ash
>= 2.11.0-rc.0, < 3.33.4
3.33.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

ash Hex → 3.33.4

mix
{:ash, "~> 3.33.4"} # then: mix deps.update ash

Severity breakdown

CVSS 4.0 0.0

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

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
Low
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
None
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-1220: Insufficient Granularity of Access Control

The product implements access controls via a policy or other feature with the intention to disable or restrict accesses (reads and/or writes) to assets in a system from untrusted agents. However, implemented access controls lack required granularity, which renders the control policy too broad because it allows accesses from unauthorized agents to the security-sensitive assets.

How to prevent it
  • Architecture and Design, Implementation, Testing: Access-control-policy protections must be reviewed for design inconsistency and common weaknesses. Access-control-policy definition and programming flow must be tested in pre-silicon, post-silicon testing.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-96581
An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's records
Not rated yet Also affects ash
EEF-CVE-2026-114214
Loading a through relationship with a limit of 1 in Ash ignores the through path and returns unrelated destination records
Not rated yet Also affects ash
EEF-CVE-2026-101028
Ash.count, Ash.exists and Ash.aggregate skip related resources' read policies in filters and sorts
Not rated yet Also affects ash
EEF-CVE-2026-94201
Filtering an :atom attribute with unsafe_to_atom? can exhaust the BEAM atom table in Ash
Not rated yet Also affects ash
EEF-CVE-2026-93477
Private action arguments can be set by user input on the bulk destroy and bulk update paths in Ash
Not rated yet Also affects ash
EEF-CVE-2026-82752
Ash string length constraints count graphemes, so a combining-mark string of any size passes max_length
Not rated yet Also affects ash
EEF-CVE-2026-82747
Ash.Policy.Authorizer returns records denied by a runtime read policy to any actor
Not rated yet Also affects ash
EEF-CVE-2026-82749
Ash relationship parent(...) filter degrades to an IS NULL match when the parent field is unresolved, leaking scoped records
Not rated yet Also affects ash

Credits: Jesse Williams, Jonatan Männchen / EEF, Zach Daniel / Ash Project

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor