Ash
Monthly
Cross-tenant record takeover in the Ash framework (Elixir) for versions 1.22.0 up to 3.37.2: when a resource uses attribute multitenancy and exposes a create action with upsert? true that accepts the primary key (or upserts on an all_tenants? identity), an authenticated user of one tenant can supply another tenant's record ID and have that record updated, its full attribute set returned, and - with default upsert fields - its tenant attribute rewritten, moving the record into the attacker's tenant. Read and update policies do not run on the upsert path, and tenant-scoped create policies pass because the tenant on the request is the caller's own, so the only meaningful preconditions are that such an action is exposed and that the attacker knows or can enumerate a foreign key (for example a serial integer ID or an ID leaked through a shared link or export). The vendor has released a fix in ash 3.37.2; no public exploit code was identified at time of analysis, and the priority signal is to patch this week rather than an emergency response.
Atom table exhaustion in the Ash framework (Elixir) allows an unauthenticated remote attacker to crash a BEAM node by supplying filter values for a publicly filterable :atom-typed attribute that is declared with the unsafe_to_atom?: true constraint. Each distinct attacker-controlled string is interned with String.to_atom/1; atoms are never garbage collected and the VM's atom table is fixed in size, so a flood of distinct values exhausts the table and terminates the node. The condition is version- and configuration-dependent: ash from 3.5.1 before 3.34.3 is affected, unsafe_to_atom?: true is not the default, and the vulnerable path is only reachable through a filter interface the attacker can query - AshPaperTrail meets that bar out of the box because its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true. A vendor patch is available in 3.34.3 and no public exploit code was identified at time of analysis.
An incorrect authorization flaw in the Elixir Ash framework (versions 3.24.0 up to but not including 3.37.1) lets an authenticated client read destination records that are unrelated to the source record when a `through` relationship is loaded for a single record with a caller-controlled `limit: 1` and optional `offset`. The vulnerable path in `lateral_join?/4` skips the filter that ties the destination back to the source, so a client paging a field such as `teachers(limit: 1, offset: n)` through AshGraphql can walk through destination records that the destination's policies only permit when reached via that relationship. Exploitation requires an authenticated session and a deployment that exposes such a `through` relationship to caller-controlled paging while relying on `accessing_from` in destination read policies; no public exploit was identified at time of analysis, and the vendor has released a fix in 3.37.1.
Information disclosure in the Ash framework for Elixir (versions 2.6.0 up to but not including 3.34.6) lets an authenticated actor infer the existence and attribute values of related records they are not authorized to read. Because the aggregate code path (Ash.Actions.Aggregate.run/4) applied only the root resource's read policy and skipped the per-related-resource read policies that the normal read path enforces, a caller who can influence filter or sort input on Ash.count/2, Ash.exists/2, or Ash.aggregate/3 can probe conditions against hidden rows and recover their contents one query at a time. Concrete exposure paths named in the advisory are Ash.Query.filter_input/2, ash_lua scripts, and AshAi tools that expose count or exists results; the vendor rates this 6.0 under CVSS 4.0 and our independent assessment places it at CVSS 3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, and no public exploit identified at time of analysis.
Improperly controlled modification of dynamically-determined object attributes in the Ash framework for Elixir (ash 2.17.15 through 3.33.10) lets a caller set private action arguments, declared with public?: false, on the bulk update and bulk destroy code paths. The affected matching logic in Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 compares every key of a caller-supplied parameter map against all of the action's arguments without checking public?, so any application that forwards end-user parameters into Ash.bulk_update/4 or Ash.bulk_destroy/4 (for example via AshJsonApi, AshGraphql, or a controller) can have a private argument injected; when that argument is referenced by an arg(...) template driving authorization, record ownership, or audit metadata, the result is an integrity violation or privilege escalation. The vendor has released a patch in 3.33.11 that requires public? in the bulk argument matching; no public exploit code has been identified at time of analysis, and the impact is conditional on the application both exposing a bulk action to untrusted input and using a security-relevant private argument.
An authorization bypass in the Ash framework (Elixir) lets authenticated, lower-privileged actors recover values they are not permitted to see by using filtered calculations or aggregates as a yes/no oracle. Ash field policies are designed to protect against filter-based disclosure by rewriting references to forbidden attributes into an expression that evaluates to nil, but prior to 3.33.4 that rewriting only matched Ash.Resource.* structs and not Ash.Query.Calculation or Ash.Query.Aggregate structs, so filters on those ran against real values. Any application that uses Ash.Policy.Authorizer with field policies on calculations or aggregates and exposes filter arguments (commonly via AshGraphql or AshJsonApi) is affected; no public exploit identified at time of analysis, and the disclosure is gradual - one probe at a time - with no integrity or availability impact.
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.
Cross-tenant record takeover in the Ash framework (Elixir) for versions 1.22.0 up to 3.37.2: when a resource uses attribute multitenancy and exposes a create action with upsert? true that accepts the primary key (or upserts on an all_tenants? identity), an authenticated user of one tenant can supply another tenant's record ID and have that record updated, its full attribute set returned, and - with default upsert fields - its tenant attribute rewritten, moving the record into the attacker's tenant. Read and update policies do not run on the upsert path, and tenant-scoped create policies pass because the tenant on the request is the caller's own, so the only meaningful preconditions are that such an action is exposed and that the attacker knows or can enumerate a foreign key (for example a serial integer ID or an ID leaked through a shared link or export). The vendor has released a fix in ash 3.37.2; no public exploit code was identified at time of analysis, and the priority signal is to patch this week rather than an emergency response.
Atom table exhaustion in the Ash framework (Elixir) allows an unauthenticated remote attacker to crash a BEAM node by supplying filter values for a publicly filterable :atom-typed attribute that is declared with the unsafe_to_atom?: true constraint. Each distinct attacker-controlled string is interned with String.to_atom/1; atoms are never garbage collected and the VM's atom table is fixed in size, so a flood of distinct values exhausts the table and terminates the node. The condition is version- and configuration-dependent: ash from 3.5.1 before 3.34.3 is affected, unsafe_to_atom?: true is not the default, and the vulnerable path is only reachable through a filter interface the attacker can query - AshPaperTrail meets that bar out of the box because its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true. A vendor patch is available in 3.34.3 and no public exploit code was identified at time of analysis.
An incorrect authorization flaw in the Elixir Ash framework (versions 3.24.0 up to but not including 3.37.1) lets an authenticated client read destination records that are unrelated to the source record when a `through` relationship is loaded for a single record with a caller-controlled `limit: 1` and optional `offset`. The vulnerable path in `lateral_join?/4` skips the filter that ties the destination back to the source, so a client paging a field such as `teachers(limit: 1, offset: n)` through AshGraphql can walk through destination records that the destination's policies only permit when reached via that relationship. Exploitation requires an authenticated session and a deployment that exposes such a `through` relationship to caller-controlled paging while relying on `accessing_from` in destination read policies; no public exploit was identified at time of analysis, and the vendor has released a fix in 3.37.1.
Information disclosure in the Ash framework for Elixir (versions 2.6.0 up to but not including 3.34.6) lets an authenticated actor infer the existence and attribute values of related records they are not authorized to read. Because the aggregate code path (Ash.Actions.Aggregate.run/4) applied only the root resource's read policy and skipped the per-related-resource read policies that the normal read path enforces, a caller who can influence filter or sort input on Ash.count/2, Ash.exists/2, or Ash.aggregate/3 can probe conditions against hidden rows and recover their contents one query at a time. Concrete exposure paths named in the advisory are Ash.Query.filter_input/2, ash_lua scripts, and AshAi tools that expose count or exists results; the vendor rates this 6.0 under CVSS 4.0 and our independent assessment places it at CVSS 3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N, and no public exploit identified at time of analysis.
Improperly controlled modification of dynamically-determined object attributes in the Ash framework for Elixir (ash 2.17.15 through 3.33.10) lets a caller set private action arguments, declared with public?: false, on the bulk update and bulk destroy code paths. The affected matching logic in Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 compares every key of a caller-supplied parameter map against all of the action's arguments without checking public?, so any application that forwards end-user parameters into Ash.bulk_update/4 or Ash.bulk_destroy/4 (for example via AshJsonApi, AshGraphql, or a controller) can have a private argument injected; when that argument is referenced by an arg(...) template driving authorization, record ownership, or audit metadata, the result is an integrity violation or privilege escalation. The vendor has released a patch in 3.33.11 that requires public? in the bulk argument matching; no public exploit code has been identified at time of analysis, and the impact is conditional on the application both exposing a bulk action to untrusted input and using a security-relevant private argument.
An authorization bypass in the Ash framework (Elixir) lets authenticated, lower-privileged actors recover values they are not permitted to see by using filtered calculations or aggregates as a yes/no oracle. Ash field policies are designed to protect against filter-based disclosure by rewriting references to forbidden attributes into an expression that evaluates to nil, but prior to 3.33.4 that rewriting only matched Ash.Resource.* structs and not Ash.Query.Calculation or Ash.Query.Aggregate structs, so filters on those ran against real values. Any application that uses Ash.Policy.Authorizer with field policies on calculations or aggregates and exposes filter arguments (commonly via AshGraphql or AshJsonApi) is affected; no public exploit identified at time of analysis, and the disclosure is gradual - one probe at a time - with no integrity or availability impact.
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.