Am I affected?
Description
Not Failing Securely (Failing Open) vulnerability in ash-project ash skips an Ash.Reactor change when the guard controlling it raises, so a change meant to run does not.
An Ash.Reactor change step can be gated by where validations that decide whether the change runs. Ash.Reactor.ChangeStep (lib/ash/reactor/steps/change_step.ex) evaluated those guards in apply_where_clauses/3, and apply_validation rescued any exception into {:error, error}. The reduce treated that identically to a guard whose condition was simply not met and bypassed the change. So when a guard raises (for example on attacker-influenced input), a change that enforces a security-relevant modification is skipped rather than failing the step. The fix distinguishes a raised exception (now {:raised, error}) and halts the step with an error, failing closed.
This issue affects ash: from 3.0.0-rc.17 before 3.32.2.
Weaknesses & attack patterns
Weakness
CWE-636
·
Not Failing Securely ('Failing Open')
in catalog →
MITRE ↗
Attack patterns
CAPEC-153
·
Input Data Manipulation
MITRE ↗
Affected — Hex / ash Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / ash-project/ash Repository ↗
modules · source files · routines
References
GHSA-3xq4-m876-fr88 ↗
vendor-advisory
EEF-CVE-2026-82744 ↗
related
Credits
CVSS breakdown
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N