CVE-2026-82744: Ash.Reactor change step fails open, skipping a change when its where guard raises
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/changestep.ex) evaluated those guards in applywhereclauses/3, and applyvalidation 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ashto a version that resolves this vulnerability.Fixed in 3.32.2
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments using ash versions from 3.0.0-rc.17 up to, but not including, 3.32.2 are affected. The exposed behavior is specifically in Ash.Reactor change steps that use where validations to decide whether a change runs.
What does an attacker need to exploit this behavior?
An attacker would need to cause a where guard for an Ash.Reactor change step to raise an exception, such as through attacker-influenced input. When that occurs, the affected versions treat the exception like an unmet condition and skip the change instead of failing the step.
What is the impact if the skipped change is security-relevant?
A security-relevant modification that was intended to run can be bypassed because the change step is skipped. Whether this creates a practical security impact depends on what the guarded change enforces in the application's Reactor configuration.
What should be done if immediate upgrading is not possible?
Review Ash.Reactor change steps with where validations, especially where guard evaluation can receive attacker-influenced input or can raise exceptions. Ensure guard failures are handled as errors rather than allowing a failed guard evaluation to result in the security-relevant change being bypassed.
How can I tell whether an attempted exploitation occurred?
Look for cases where an Ash.Reactor where validation raised an exception and the associated change was bypassed rather than the step failing. The provided information does not specify particular log messages or indicators for detecting these events.