Ash
Monthly
Unbounded string storage in Ash Framework versions 0.10.0 through 3.32.x allows unauthenticated attackers to bypass max_length and min_length constraints by submitting Unicode strings whose grapheme count is small but whose codepoint and byte footprint is arbitrarily large. Ash's constraint logic calls Elixir's String.length/1, which counts graphemes; a single base character followed by millions of combining accent codepoints is one grapheme but megabytes of data, satisfying max_length: 2 while writing the entire payload to storage. When the backing store is a PostgreSQL text column, ETS table, or Mnesia table, the oversized value is persisted without limit, enabling storage exhaustion. No public exploit code or CISA KEV listing exists at the time of analysis.
Record-level authorization bypass in Ash (ash-project) versions 3.4.44 through 3.32.1 silently leaks denied records to any actor when resources use access_type :runtime read policies. A logic error in Ash.Policy.Authorizer.check_result/1 causes the empty-scenario branch - reached when all policy paths for a record are impossible and the record must be forbidden - to instead keep and return the record as authorized. No public exploit has been identified at time of analysis; the vendor confirmed the issue and released a fix in version 3.32.2.
Incorrect authorization in ash-project/ash (Elixir data framework) versions 3.13.2 through 3.32.1 causes relationship scoping filters that reference parent() expressions to silently widen when the parent field cannot be resolved. The function resolve_parent_in_filter/3 defaulted the unresolvable expression to nil rather than failing, converting a guard such as org_id == parent(org_id) into an org_id IS NULL match, or activating the unrestricted branch of is_nil(parent(org_id)) or org_id == parent(org_id), thereby returning records the scope was designed to exclude. No public exploit has been identified at time of analysis; a vendor-released patch is available in ash 3.32.2.
Incorrect authorization in the Ash Elixir framework (versions 3.5.13 through 3.32.2) allows aggregate queries to execute under a more permissive read action than the one used during the authorization check, disclosing aggregate-level statistics about records the actor is not permitted to access. The flaw lives in Ash.Actions.Aggregate, where the data-query builder honored an opts[:action] override that diverged from the read_action used to compute policy groups. No public exploit is identified at time of analysis, and a vendor-released patch is available in version 3.32.2.
Authorization policy bypass in Ash (Elixir framework) versions 3.29.0-3.32.1 permits any application actor to modify records protected by resource policies when using the atomic update path. The root cause is that `Ash.Actions.Update.UpdateMany` selected the atomic strategy under `authorize?: true` without invoking the authorization layer, causing the resulting SQL MERGE to update all primary-key-matched rows without applying policy filters. No public exploit code has been identified at time of analysis, but the published patch commit and GHSA advisory provide sufficient detail to reconstruct the bypass; the fix is vendor-confirmed in version 3.32.2.
Silent record overwrite in Ash's ETS and Mnesia data layers allows any actor who can supply a primary key on a create action to replace an existing record without triggering update action authorization policies. Versions 0.4.0 through 3.32.1 are affected; only deployments using the ETS or Mnesia data layer - not SQL-backed layers - are vulnerable. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the integrity impact is high for applications that expose user-controlled primary key creation.
Ash.Reactor's ChangeStep component in the Elixir Ash framework silently bypasses security-relevant change operations when a `where` guard raises an exception, instead of halting the step with an error. Applications built on ash versions 3.0.0-rc.17 through 3.32.1 that use Ash.Reactor pipelines with `where`-gated changes are affected. An attacker who can supply crafted input triggering a guard exception may cause the guarded change to be silently skipped, potentially circumventing authentication, authorization, or mandatory data transformations depending on what that change enforces. No public exploit has been identified and the vulnerability is not listed in CISA KEV.
Scheduler exhaustion in ash Framework (Elixir) versions 2.19.0 through 3.32.2 allows any workload triggering concurrent slow async read operations to pin BEAM scheduler threads at 100% CPU. The root cause is a busy-polling loop in Ash.Actions.Read.AsyncLimiter.await_at_least_one/1 that called Task.yield(task, 0) repeatedly with zero timeout rather than sleeping until a task completed, keeping the calling scheduler thread active throughout the wait. Multiple concurrent slow related-data loads or calculations compound the impact by saturating additional scheduler threads, potentially degrading or denying service to the entire Elixir node. No public exploit identified at time of analysis; vendor-released patch ash 3.32.2 resolves the issue.
Memory exhaustion in Ash Framework's runtime filter engine allows an attacker controlling filter inputs to crash an Elixir node by submitting a query that spans multiple to-many relationships against large in-memory datasets. The vulnerable `flatten_relationships/2` function in `lib/ash/filter/runtime.ex` (versions 1.29.0-rc0 through 3.32.2) eagerly materializes the full Cartesian product of related rows before evaluating any predicate, producing O(M^K) intermediate records for K relationships with M rows each. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 3.32.2.
Type confusion in Ash Framework's union type storage allows attackers to persist a crafted map value whose data belongs to one union member but whose tag names a different member, bypassing that member's constraints and any tag-based authorization policies. Affected versions span ash 2.14.18 through 3.32.2 (exclusive). This exploits `Ash.Type.Union.dump_to_native/2` only when union fields are configured with `storage: :map_with_tag`, a non-default specialization. No public exploit is identified and the issue carries a very low CVSS 4.0 base score of 2.1, but the authentication bypass impact is notable in policy-sensitive applications.
Outer array constraint bypass in ash-project Ash (versions 2.16.1 through <3.32.2) allows input that violates declared outer-array constraints on doubly-nested {:array, {:array, type}} attributes to be accepted and persisted without error. The defect in Ash.Type.apply_constraints/3 propagated only inner-array constraints during nested array validation, leaving outer constraints such as max_length, min_length, and nil_items? unenforced. No active exploitation has been confirmed and no public exploit code is known at time of analysis; a vendor-released patch is available in version 3.32.2.
Sensitive field value disclosure in Ash Framework's atomic confirmation validator allows any caller of a vulnerable action to extract a stored sensitive attribute by intentionally submitting a wrong confirmation argument. Versions 2.17.20 through before 3.32.2 of ash-project/ash are affected: when an actor supplies only the confirmation argument and omits the field itself, the atomic `Confirm` validator resolves the mismatch error's `value` through `atomic_ref/2` to the field's current stored database value and returns it in the error payload. No public exploit exists beyond the regression test shipped with the fix commit, and this vulnerability does not appear in the CISA KEV catalog.
Persistent record-level denial of service in the ash Elixir resource framework (versions 3.6.3-3.32.1) lets any actor who can write a non-version-7 UUID into an Ash.Type.UUIDv7 attribute permanently break all subsequent reads of that database row. The root cause is a validation asymmetry introduced in v3.6.3: cast_input/2 was tightened to reject non-v7 16-byte binaries, but cast_stored/2 continued delegating to cast_input/2, so a stored non-v7 binary now returns :error on every read. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog; vendor-released patch v3.32.2 is available.
Integer overflow in Ash Framework's vector encoding corrupts stored vectors in any Elixir application using Ash versions 2.14.13 through 3.32.1, enabling persistent denial of service against affected database records. The dimension count for a vector submitted with more than 65,535 elements silently wraps modulo 65,536 in a 16-bit header field, causing every subsequent read of the corrupted record to raise an exception. Applications that expose vector ingestion to untrusted users are at risk of permanent per-record data loss; no public exploit has been identified at time of analysis.
Constraint bypass in Ash Framework's CiString type allows storing string values that violate configured length or match constraints after case-folding. Any application built on ash versions 1.29.0-rc0 through 3.32.2 that defines a CiString attribute with both a casing option (:lower or :upper) and a max_length, min_length, or match constraint is affected. An attacker who can submit input to such a field can craft a value whose pre-fold form satisfies constraints but whose stored, case-folded form violates them - silently defeating application-defined data integrity rules. No public exploit code exists and no CISA KEV listing is present; the CVSS 4.0 score of 2.1 reflects the narrow, low-severity nature of the flaw.
CPU exhaustion in Ash Framework's string type constraint handler allows denial of service against Elixir applications that use Ash string attribute validation with both length and regex match constraints. The `Ash.Type.String.apply_constraints/2` function evaluated the `:match` regex unconditionally, even when a length constraint had already failed, allowing attacker-controlled input of arbitrary size to reach the regex engine directly. Against backtracking patterns this produces catastrophic exponential evaluation time; against linear patterns, CPU cost scales with input size, enabling sustained per-request service degradation. No public exploit has been identified at time of analysis.
Constraint validation bypass in Ash Framework's decimal type (versions 1.28.0 through 3.32.1) allows any actor capable of submitting input to an Ash action with a decimal field to persist non-finite IEEE 754 values such as Infinity or NaN, silently bypassing configured min/max bounds. Because NaN returns false in all numeric comparisons, constraint checks pass without error; the persisted value then causes arithmetic failures or data-layer rejections in subsequent operations, degrading application integrity and availability. No active exploitation is confirmed (not in CISA KEV) and no public exploit code exists; vendor patch is available in version 3.32.2.
Query injection and oracle enumeration in Ash Framework (ash-project/ash) versions 1.52.0-rc.11 through pre-3.31.1 allow an attacker to forge a belongs_to relationship to a record whose identifier they cannot directly name, and to systematically recover secret lookup values via a comparison oracle. The root cause is a two-part failure in the managed_relationship on_lookup: :relate code path: client-supplied values reach Ash.Query.filter/2 without type-casting, so a nested map is interpreted as a filter predicate rather than a literal scalar, and the missing Ash.Query.limit(1) call lets Ash.read_one/2 distinguish zero, one, and multiple matches - converting boolean filter predicates into an oracle. No public exploit has been identified at time of analysis; a vendor patch is available at version 3.31.1.
Memory exhaustion via decompression bomb in Ash Framework's keyset pagination can terminate Erlang nodes running versions 1.17.0 through 3.31.0. The `decode_values/2` function in `lib/ash/page/keyset.ex` deserializes client-supplied `page[:after]` or `page[:before]` cursors using `:erlang.binary_to_term/2` without rejecting compressed Erlang external term format payloads or bounding the deserialized size, allowing a cursor of a few kilobytes on the wire to inflate to tens of megabytes of heap per request. No active exploitation (CISA KEV) has been identified, but the attack is mechanically trivial for any caller reaching a keyset-paginated endpoint, and the vendor patch test suite includes a working reproduction payload.
Private argument injection in the Ash Elixir framework (versions 3.0.0 through 3.29.2) allows end users to set action arguments explicitly marked public?: false, which are designed to be controlled exclusively by trusted server-side code. The filtering logic in both the regular changeset path and the atomic changeset path fails to enforce the public? flag when input parameters arrive as string (binary) keys - the default format for user-supplied JSON or form data. An attacker who submits a string-keyed parameter matching a private argument name can inject an arbitrary value, potentially enabling privilege escalation or integrity violations if that argument drives authorization decisions such as acting_user_id or record ownership. No public exploit code has been identified and this vulnerability is not listed in CISA KEV.
An issue was discovered in the ash crate before 0.33.1 for Rust. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
Unbounded string storage in Ash Framework versions 0.10.0 through 3.32.x allows unauthenticated attackers to bypass max_length and min_length constraints by submitting Unicode strings whose grapheme count is small but whose codepoint and byte footprint is arbitrarily large. Ash's constraint logic calls Elixir's String.length/1, which counts graphemes; a single base character followed by millions of combining accent codepoints is one grapheme but megabytes of data, satisfying max_length: 2 while writing the entire payload to storage. When the backing store is a PostgreSQL text column, ETS table, or Mnesia table, the oversized value is persisted without limit, enabling storage exhaustion. No public exploit code or CISA KEV listing exists at the time of analysis.
Record-level authorization bypass in Ash (ash-project) versions 3.4.44 through 3.32.1 silently leaks denied records to any actor when resources use access_type :runtime read policies. A logic error in Ash.Policy.Authorizer.check_result/1 causes the empty-scenario branch - reached when all policy paths for a record are impossible and the record must be forbidden - to instead keep and return the record as authorized. No public exploit has been identified at time of analysis; the vendor confirmed the issue and released a fix in version 3.32.2.
Incorrect authorization in ash-project/ash (Elixir data framework) versions 3.13.2 through 3.32.1 causes relationship scoping filters that reference parent() expressions to silently widen when the parent field cannot be resolved. The function resolve_parent_in_filter/3 defaulted the unresolvable expression to nil rather than failing, converting a guard such as org_id == parent(org_id) into an org_id IS NULL match, or activating the unrestricted branch of is_nil(parent(org_id)) or org_id == parent(org_id), thereby returning records the scope was designed to exclude. No public exploit has been identified at time of analysis; a vendor-released patch is available in ash 3.32.2.
Incorrect authorization in the Ash Elixir framework (versions 3.5.13 through 3.32.2) allows aggregate queries to execute under a more permissive read action than the one used during the authorization check, disclosing aggregate-level statistics about records the actor is not permitted to access. The flaw lives in Ash.Actions.Aggregate, where the data-query builder honored an opts[:action] override that diverged from the read_action used to compute policy groups. No public exploit is identified at time of analysis, and a vendor-released patch is available in version 3.32.2.
Authorization policy bypass in Ash (Elixir framework) versions 3.29.0-3.32.1 permits any application actor to modify records protected by resource policies when using the atomic update path. The root cause is that `Ash.Actions.Update.UpdateMany` selected the atomic strategy under `authorize?: true` without invoking the authorization layer, causing the resulting SQL MERGE to update all primary-key-matched rows without applying policy filters. No public exploit code has been identified at time of analysis, but the published patch commit and GHSA advisory provide sufficient detail to reconstruct the bypass; the fix is vendor-confirmed in version 3.32.2.
Silent record overwrite in Ash's ETS and Mnesia data layers allows any actor who can supply a primary key on a create action to replace an existing record without triggering update action authorization policies. Versions 0.4.0 through 3.32.1 are affected; only deployments using the ETS or Mnesia data layer - not SQL-backed layers - are vulnerable. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, but the integrity impact is high for applications that expose user-controlled primary key creation.
Ash.Reactor's ChangeStep component in the Elixir Ash framework silently bypasses security-relevant change operations when a `where` guard raises an exception, instead of halting the step with an error. Applications built on ash versions 3.0.0-rc.17 through 3.32.1 that use Ash.Reactor pipelines with `where`-gated changes are affected. An attacker who can supply crafted input triggering a guard exception may cause the guarded change to be silently skipped, potentially circumventing authentication, authorization, or mandatory data transformations depending on what that change enforces. No public exploit has been identified and the vulnerability is not listed in CISA KEV.
Scheduler exhaustion in ash Framework (Elixir) versions 2.19.0 through 3.32.2 allows any workload triggering concurrent slow async read operations to pin BEAM scheduler threads at 100% CPU. The root cause is a busy-polling loop in Ash.Actions.Read.AsyncLimiter.await_at_least_one/1 that called Task.yield(task, 0) repeatedly with zero timeout rather than sleeping until a task completed, keeping the calling scheduler thread active throughout the wait. Multiple concurrent slow related-data loads or calculations compound the impact by saturating additional scheduler threads, potentially degrading or denying service to the entire Elixir node. No public exploit identified at time of analysis; vendor-released patch ash 3.32.2 resolves the issue.
Memory exhaustion in Ash Framework's runtime filter engine allows an attacker controlling filter inputs to crash an Elixir node by submitting a query that spans multiple to-many relationships against large in-memory datasets. The vulnerable `flatten_relationships/2` function in `lib/ash/filter/runtime.ex` (versions 1.29.0-rc0 through 3.32.2) eagerly materializes the full Cartesian product of related rows before evaluating any predicate, producing O(M^K) intermediate records for K relationships with M rows each. No public exploit has been identified at time of analysis; a vendor-released patch is available in version 3.32.2.
Type confusion in Ash Framework's union type storage allows attackers to persist a crafted map value whose data belongs to one union member but whose tag names a different member, bypassing that member's constraints and any tag-based authorization policies. Affected versions span ash 2.14.18 through 3.32.2 (exclusive). This exploits `Ash.Type.Union.dump_to_native/2` only when union fields are configured with `storage: :map_with_tag`, a non-default specialization. No public exploit is identified and the issue carries a very low CVSS 4.0 base score of 2.1, but the authentication bypass impact is notable in policy-sensitive applications.
Outer array constraint bypass in ash-project Ash (versions 2.16.1 through <3.32.2) allows input that violates declared outer-array constraints on doubly-nested {:array, {:array, type}} attributes to be accepted and persisted without error. The defect in Ash.Type.apply_constraints/3 propagated only inner-array constraints during nested array validation, leaving outer constraints such as max_length, min_length, and nil_items? unenforced. No active exploitation has been confirmed and no public exploit code is known at time of analysis; a vendor-released patch is available in version 3.32.2.
Sensitive field value disclosure in Ash Framework's atomic confirmation validator allows any caller of a vulnerable action to extract a stored sensitive attribute by intentionally submitting a wrong confirmation argument. Versions 2.17.20 through before 3.32.2 of ash-project/ash are affected: when an actor supplies only the confirmation argument and omits the field itself, the atomic `Confirm` validator resolves the mismatch error's `value` through `atomic_ref/2` to the field's current stored database value and returns it in the error payload. No public exploit exists beyond the regression test shipped with the fix commit, and this vulnerability does not appear in the CISA KEV catalog.
Persistent record-level denial of service in the ash Elixir resource framework (versions 3.6.3-3.32.1) lets any actor who can write a non-version-7 UUID into an Ash.Type.UUIDv7 attribute permanently break all subsequent reads of that database row. The root cause is a validation asymmetry introduced in v3.6.3: cast_input/2 was tightened to reject non-v7 16-byte binaries, but cast_stored/2 continued delegating to cast_input/2, so a stored non-v7 binary now returns :error on every read. No public exploit code has been identified and the vulnerability is not listed in the CISA KEV catalog; vendor-released patch v3.32.2 is available.
Integer overflow in Ash Framework's vector encoding corrupts stored vectors in any Elixir application using Ash versions 2.14.13 through 3.32.1, enabling persistent denial of service against affected database records. The dimension count for a vector submitted with more than 65,535 elements silently wraps modulo 65,536 in a 16-bit header field, causing every subsequent read of the corrupted record to raise an exception. Applications that expose vector ingestion to untrusted users are at risk of permanent per-record data loss; no public exploit has been identified at time of analysis.
Constraint bypass in Ash Framework's CiString type allows storing string values that violate configured length or match constraints after case-folding. Any application built on ash versions 1.29.0-rc0 through 3.32.2 that defines a CiString attribute with both a casing option (:lower or :upper) and a max_length, min_length, or match constraint is affected. An attacker who can submit input to such a field can craft a value whose pre-fold form satisfies constraints but whose stored, case-folded form violates them - silently defeating application-defined data integrity rules. No public exploit code exists and no CISA KEV listing is present; the CVSS 4.0 score of 2.1 reflects the narrow, low-severity nature of the flaw.
CPU exhaustion in Ash Framework's string type constraint handler allows denial of service against Elixir applications that use Ash string attribute validation with both length and regex match constraints. The `Ash.Type.String.apply_constraints/2` function evaluated the `:match` regex unconditionally, even when a length constraint had already failed, allowing attacker-controlled input of arbitrary size to reach the regex engine directly. Against backtracking patterns this produces catastrophic exponential evaluation time; against linear patterns, CPU cost scales with input size, enabling sustained per-request service degradation. No public exploit has been identified at time of analysis.
Constraint validation bypass in Ash Framework's decimal type (versions 1.28.0 through 3.32.1) allows any actor capable of submitting input to an Ash action with a decimal field to persist non-finite IEEE 754 values such as Infinity or NaN, silently bypassing configured min/max bounds. Because NaN returns false in all numeric comparisons, constraint checks pass without error; the persisted value then causes arithmetic failures or data-layer rejections in subsequent operations, degrading application integrity and availability. No active exploitation is confirmed (not in CISA KEV) and no public exploit code exists; vendor patch is available in version 3.32.2.
Query injection and oracle enumeration in Ash Framework (ash-project/ash) versions 1.52.0-rc.11 through pre-3.31.1 allow an attacker to forge a belongs_to relationship to a record whose identifier they cannot directly name, and to systematically recover secret lookup values via a comparison oracle. The root cause is a two-part failure in the managed_relationship on_lookup: :relate code path: client-supplied values reach Ash.Query.filter/2 without type-casting, so a nested map is interpreted as a filter predicate rather than a literal scalar, and the missing Ash.Query.limit(1) call lets Ash.read_one/2 distinguish zero, one, and multiple matches - converting boolean filter predicates into an oracle. No public exploit has been identified at time of analysis; a vendor patch is available at version 3.31.1.
Memory exhaustion via decompression bomb in Ash Framework's keyset pagination can terminate Erlang nodes running versions 1.17.0 through 3.31.0. The `decode_values/2` function in `lib/ash/page/keyset.ex` deserializes client-supplied `page[:after]` or `page[:before]` cursors using `:erlang.binary_to_term/2` without rejecting compressed Erlang external term format payloads or bounding the deserialized size, allowing a cursor of a few kilobytes on the wire to inflate to tens of megabytes of heap per request. No active exploitation (CISA KEV) has been identified, but the attack is mechanically trivial for any caller reaching a keyset-paginated endpoint, and the vendor patch test suite includes a working reproduction payload.
Private argument injection in the Ash Elixir framework (versions 3.0.0 through 3.29.2) allows end users to set action arguments explicitly marked public?: false, which are designed to be controlled exclusively by trusted server-side code. The filtering logic in both the regular changeset path and the atomic changeset path fails to enforce the public? flag when input parameters arrive as string (binary) keys - the default format for user-supplied JSON or form data. An attacker who submits a string-keyed parameter matching a private argument name can inject an arbitrary value, potentially enabling privilege escalation or integrity violations if that argument drives authorization decisions such as acting_user_id or record ownership. No public exploit code has been identified and this vulnerability is not listed in CISA KEV.
An issue was discovered in the ash crate before 0.33.1 for Rust. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.