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.
Published: 2026-09-01
Score: 2.1 Low
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

An Ash.Reactor change step can be gated by where validations that decide whether the change runs. When the guard raises an exception, the change step mistakenly skips the intended change instead of failing the step. This failure‑to‑fail outcome allows a potential attacker to trigger a guard exception—such as by providing crafted input—to bypass security‑relevant modifications. The vulnerability is rated a CVSS score of 2.1, indicating low severity, but it introduces a non‑fatal bypass that could undermine accountability controls. The attack vector is the ability to influence the guard condition; although the exploitability is limited, the impact is that a critical change may be omitted entirely.

Affected Systems

This issue affects the Ash project’s Ash component, with affected releases ranging from 3.0.0‑rc.17 up to but not including 3.32.2. System administrators using any of those versions should verify whether they rely on Ash.Reactor change steps with strict security enforcement. The underlying library, Ash.Reactor, is distributed under the Ash project brand and versions prior to 3.32.2 are impacted.

Risk and Exploitability

The CVSS score of 2.1 and the absence of an EPSS value suggest a low likelihood of widespread exploitation. The vulnerability is not listed in the CISA KEV catalog, further indicating that no public exploits are known. Nevertheless, the flaw can be leveraged by an attacker capable of provoking a guard exception, such as via input that the guard is not prepared to handle. Even though the exploit does not result in immediate system compromise, the risk lies in inadvertent bypass of critical change logic, potentially eroding security postures.

Generated by OpenCVE AI on September 1, 2026 at 05:27 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade ash-project ash to version 3.32.2 or later, which contains the fix that distinguishes raised exceptions and halts the step instead of skipping it.
  • Review and test existing Ash.Reactor change steps to ensure that any guard failures are treated as critical errors and not ignored; consider adding explicit error handling or logs to flag unexpected guard exceptions.
  • Monitor application logs for recurring {:raised, error} patterns that indicate an attempted bypass, and investigate the source of those inputs to prevent future exploitation attempts.

Generated by OpenCVE AI on September 1, 2026 at 05:27 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Tue, 01 Sep 2026 04:00:00 +0000

Type Values Removed Values Added
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.
Title Ash.Reactor change step fails open, skipping a change when its where guard raises
First Time appeared Ash-project
Ash-project ash
Weaknesses CWE-636
CPEs cpe:2.3:a:ash-project:ash:*:*:*:*:*:*:*:*
Vendors & Products Ash-project
Ash-project ash
References
Metrics cvssV4_0

{'score': 2.1, 'vector': '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'}


cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-09-01T03:39:42.668Z

Reserved: 2026-08-31T01:00:09.774Z

Link: CVE-2026-82744

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-09-01T04:18:04.600

Modified: 2026-09-01T04:18:04.600

Link: CVE-2026-82744

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-01T05:45:04Z

Weaknesses
  • CWE-636

    Not Failing Securely ('Failing Open')