Ash.Reactor change step fails open, skipping a change when its where guard raises
## Summary 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.
describes (1)
Related CVEs.
| ID | severity | exploitable | ||
|---|---|---|---|---|
| CVE-2026-82744US | — | — | ||
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.Re… | ||||
references
External citations — patches, advisories, analysis.
Advisories like this name the exposed products attackers go after on your perimeter. See what is exposed on your perimeter with a free passive scan.
Free scan