Ash Project
Monthly
Sensitive field disclosure in ash_lua (versions 0.1.0 through 0.2.0) allows any actor who can submit a Lua script to read Ash resource attributes that are deliberately excluded from the manifest's exposed-field allow-list - including sensitive?: true columns such as hashed passwords. The operation aggregate path in AshLua.Runtime resolved field names directly via String.to_existing_atom and Ash.Query.Aggregate.new! without invoking the same AshLua.Fields.for_action/4 allow-list check enforced by the normal field-read path, creating an alternate route to private data. Vendor patch 0.2.1 is confirmed available; no CISA KEV listing or independent exploit beyond the PoC embedded in the security advisory has been identified.
Unauthenticated resource exhaustion in ash_authentication_oauth2_server 0.3.0 enables any remote attacker to grow database storage and heap memory without bound when the Client ID Metadata Document (CIMD) feature is enabled. The /authorize endpoint's resolve_client/3 function fetches and permanently upserts one database row per distinct URL-shaped client_id, with no row cap, no TTL-based expiry, and no field-length limit; additionally, fetched documents enter CIMD.Cache before validation, meaning even rejected documents consume cache memory until their TTL expires. No public exploit code or active exploitation has been identified at time of analysis.
Unauthenticated atom table exhaustion in ash_typescript 0.1.0-0.17.x allows any network attacker to crash the entire Erlang/BEAM node by submitting RPC requests with attacker-controlled field names. The library's `convert_to_field_atom/2` function calls `String.to_atom/1` on client-supplied strings without validation, minting permanent, non-garbage-collected atoms until the VM hits its table limit and aborts. Additionally, field names exceeding 255 characters trigger an uncaught `SystemLimitError`. No public exploit is identified at time of analysis, but exploitation is trivial given no authentication or special configuration is required.
Field policy enforcement in ash_typescript RPC serialization is bypassed by a missing pattern-match clause, allowing unauthenticated remote callers to receive the real values of attributes that Ash field policies explicitly denied. Any action returning an embedded resource through the RPC layer exposes policy-protected fields - including sensitive PII such as SSNs, as demonstrated in the patch test suite - inside the serialized JSON response. Affects ash_typescript 0.11.0 through 0.17.x; no public exploit code exists at time of analysis, but the attack path is fully described in the vendor advisory and the two-line fix diff.
Unauthenticated BEAM atom table exhaustion in ash_typescript 0.11.0-0.17.x allows a remote attacker to abort the Erlang VM and take down the entire application node by sending RPC requests carrying many distinct, unrecognized field names targeting a typed struct field selector. The root cause is `resolve_typed_struct_field/2` calling `String.to_atom/1` on unresolvable client input before any field-existence validation, permanently minting atoms that the BEAM runtime never reclaims. A vendor-released patch is available in 0.18.0; no public exploit code or CISA KEV listing exists at time of analysis.
Tenant authorization bypass in ash_phoenix's SubdomainHook allows an authenticated user to cross tenant boundaries and access or modify data belonging to other tenants. The flaw is rooted in a LiveView lifecycle ordering error: AshPhoenix.LiveView.SubdomainHook.on_mount/4 called the consumer-defined authorization callback before Phoenix LiveView's handle_params phase had run, guaranteeing the callback always received a nil tenant and either crashed or silently permitted the request. Critically, the flawed check was never re-evaluated on subsequent in-session navigations, so the bypass persisted for the lifetime of the LiveView connection. No public exploit has been identified at time of analysis, but the bypass is systematic and total for all affected deployments using SubdomainHook with tenant-scoped authorization callbacks.
Arbitrary file write via path traversal in AshAdmin's file upload handler affects versions 0.13.7 through 1.3.0, enabling any authenticated admin user to write attacker-controlled bytes to any filesystem path writable by the BEAM process. The root cause is that browser-supplied filenames are concatenated into upload paths via Elixir's Path.join/1 without stripping directory components, so a crafted filename such as ../../../../var/www/app/priv/static/evil.ex escapes the randomized temp directory. No public exploit has been identified at time of analysis, but the primitive directly enables remote code execution by overwriting application modules, static assets, cron jobs, or SSH authorized_keys files.
Stored XSS in ash_admin's relationship typeahead components allows an attacker with low-privilege record-creation access to execute arbitrary JavaScript in an administrator's browser. Affected are ash_admin versions 0.13.0 through 1.3.1, where the `RelationshipField` and `ManagedRelationshipSelectField` components render database record label fields unescaped via `Phoenix.HTML.raw/1` after applying search-term highlight markup. A crafted label such as `<img src=x onerror=...>` persists in the database and fires whenever an admin's typeahead dropdown displays the matching record, granting the attacker full admin-level privileges over everything AshAdmin exposes. No public exploit code has been identified at time of analysis; a vendor-released patch is available in version 1.3.1.
Atom table exhaustion in ash_admin's Phoenix LiveView event handlers allows any authenticated user reaching the admin interface to crash the entire BEAM VM node. Two handlers - AshAdmin.PageLive's set_actor and AshAdmin.Components.Resource.Show's calculate - passed unvalidated client strings directly to Module.concat/1 and String.to_atom/1 respectively, minting a permanent new atom per unique request. Because BEAM atoms are never garbage collected and the table is capped at roughly one million entries, flooding either handler terminates the VM and takes down every Elixir application co-hosted on the node. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; patch version 1.3.1 is available.
Cookie shadowing via unanchored regex in AshAdmin (versions 0.9.1-1.3.0) allows an attacker who controls a sibling subdomain to inject state cookies that rebind an administrator's LiveSocket session to an arbitrary actor, tenant, or authorization mode - effectively bypassing the admin panel's authorization controls. The client-side JavaScript cookie parser used `new RegExp(name + "=([^;]+)")`, which matches any cookie whose name merely ends with the target name, enabling a shadowing cookie (e.g., `xactor_authorizing` over `actor_authorizing`) set from a sibling subdomain with `Domain=.example.com` to silently win. No public exploit or CISA KEV listing exists at time of analysis, but the integrity impact is high for any multi-subdomain deployment.
Credential leakage in ash_ai (versions 0.1.0 through before 1.0.0) exposes embedding provider API keys and request internals to authenticated API callers via unsanitized error messages. In AshAi.Changes.Vectorize, a failed embedding provider call caused the raw Elixir error struct - which HTTP clients commonly populate with the outbound Authorization header, request URL, and provider response body - to be passed through inspect/1 directly into a user-facing changeset error. AshJsonApi and AshGraphql serialize these changeset errors into API responses, making the full credential material readable by any caller who can trigger a provider failure. No public exploit has been identified at time of analysis, but the trigger condition (oversized or malformed vectorized content) is trivially reachable by any authenticated user of an exposed endpoint.
Authorization bypass in AshAi (ash_ai) versions 0.6.0 through pre-1.0.0 allows any authenticated tool caller to update or destroy database records it never legitimately identified, up to and including every row in a table. The flaw is in AshAi.Tool.Execution.identity_filter/3, which passes raw tool arguments directly into Ash.Query.do_filter/2; because Ash's filter DSL interprets map values as predicate expressions rather than scalar literals, a caller can inject filter logic such as {"not_eq": "<own-ref>"} to retarget bulk writes to arbitrary records. A vendor patch is available in commit 87f616d and the fix version is 1.0.0; no public exploit or CISA KEV listing exists at time of analysis.
DNS-rebinding protection in AshAi.Mcp.Server (ash_ai 0.8.0-0.x) is bypassable because the default origin check trusts the attacker-controlled Host and X-Forwarded-Proto headers as proxies for TLS context. A malicious web page can exploit this to issue arbitrary cross-site requests to the victim's locally running MCP server, executing MCP calls under the victim's actor credentials. No public exploit has been identified at time of analysis, but the attack path is mechanically straightforward for any attacker who can lure a developer to a malicious page while they have the MCP server running locally.
Remote code execution in ash_ai (versions 0.1.0 through pre-1.0.0) allows unauthenticated network attackers to execute arbitrary Elixir code on the server by submitting EEx template payloads through prompt action arguments. The AshAi.Actions.Prompt module incorrectly passed function-supplied prompt content - which is frequently assembled from user-controlled action arguments - through EEx.eval_string/2 before forwarding to the AI model, meaning payloads like <%= System.cmd("id", []) %> execute server-side with application process privileges. No public exploit code or CISA KEV listing exists at time of analysis, but the zero-authentication, single-request exploitation path gives this a higher operational priority than the EPSS percentile alone suggests.
Cross-tenant data disclosure in ash_graphql affects authenticated subscribers in multi-tenant deployments running versions 1.4.0 through 1.10.x. The subscription resolver's in-memory authorization fast path evaluates read policy filters without any tenant condition, allowing a subscriber scoped to tenant A to receive GraphQL subscription notifications carrying tenant B's records. The single-notification code path had no tenant guard at all, and the batched path checked tenant only on the list head, leaving all subsequent entries to authorize purely in memory without tenancy enforcement. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the impact is high confidentiality loss for any multi-tenant SaaS product built on this stack.
AshGraphql's Absinthe complexity calculator undercounts nested Relay connection and keyset pagination queries, allowing unauthenticated clients to bypass any configured `max_complexity` cap and force unbounded database reads. Versions 0.16.23 through 1.10.x expose this flaw whenever a schema uses `first`/`last`-based pagination: a single crafted query such as `posts(first: 500) { edges { node { comments(first: 500) { ... } } } }` scores near-zero in Absinthe's guard while materializing up to 250,000 records per request. No active exploitation is confirmed (no CISA KEV listing), but the attack requires no authentication and is trivially constructable from the public advisory description alone.
Silent schema cross-contamination in ash_postgres multi-tenancy allows a low-privileged user who can trigger a tenant rename to gain unauthorized read and write access to a different tenant's PostgreSQL schema. Affected versions span 0.25.0 through 2.13.0 of the ash-project/ash_postgres Elixir library. When PostgreSQL rejects the ALTER SCHEMA rename due to a name collision, the library silently reports success, causing the tenant metadata row to be committed pointing at the victim's live schema - routing all subsequent reads and writes for the attacker's tenant against the victim's data. No public exploit code or CISA KEV listing has been identified at time of analysis.
Field policy bypass in AshLua 0.1.0-0.2.1 allows authenticated Lua script executors to read actor-restricted fields by requesting them through aggregate operations (min, max, first, sum, avg, list) rather than as direct record fields, circumventing per-actor field policy authorization while remaining within the configured exposed-field allow-list. The Ash framework normally redacts forbidden fields on returned record structs with %Ash.ForbiddenField{}, but AshLua's read action did not apply this check when constructing ad-hoc Ash.Query.Aggregate instances, returning raw field values instead. No public exploit code exists and the vulnerability is not in CISA KEV; the CVSS 4.0 score of 6.0 reflects network-accessible but prerequisite-gated exploitation requiring authenticated script execution access.
Field policy bypass in ash_ai (versions 0.1.0 through < 1.0.3) allows authenticated, low-privilege actors to read per-actor-restricted fields - including sensitive PII - by invoking the aggregate result type (min, max, sum, avg) via the LLM read tool instead of direct record retrieval. Ash field policies redact forbidden fields on returned records by substituting %Ash.ForbiddenField{}, but this redaction mechanism was never applied to aggregate code paths; the tool's authorization check only tested field.public?, a static attribute orthogonal to per-actor policy evaluation. Patch version 1.0.3 is available via the vendor advisory; no CISA KEV listing or public exploit code has been identified at time of analysis.
Terminal escape sequence injection in ash-project/usage_rules (versions 0.1.18 through 1.2.7) allows a malicious Hex package publisher to forge what developers see when running mix usage_rules.search_docs. The Mix task queries search.hexdocs.pm and renders publisher-controlled fields - title, package name, type, doc reference, and highlighted snippets - verbatim to the terminal with no control-character sanitization, only adding ANSI highlighting rather than stripping injected sequences. A package author who embeds ANSI cursor-movement, line-erase, carriage-return, or OSC 52 clipboard-write sequences in their documentation can cause a developer's terminal to display a forged hexdocs URL, conceal output, or silently write an attacker-controlled command to the clipboard; no public exploit has been identified at time of analysis.
Terminal escape sequence injection in ash-project Igniter (versions 0.8.1-0.8.3) allows a malicious or typosquatted hex.pm package publisher to forge the `mix igniter.install` confirmation panel by embedding ANSI cursor-movement and line-erase control sequences in publisher-controlled metadata fields such as the package description, owner usernames, version, and download counts. Developers relying on this panel as an anti-typosquatting safeguard are shown attacker-crafted content that conceals the real metadata, potentially deceiving them into approving a malicious dependency. A vendor patch is available in version 0.8.4; no public exploit and no CISA KEV listing have been identified at time of analysis.
ULID first-character non-canonicality in ash_double_entry (Elixir) exposes a multi-spelling identifier aliasing flaw affecting versions 0.1.0 through 1.0.18. The AshDoubleEntry.ULID type encodes 128-bit identifiers as 26 Crockford base-32 characters, but the first character carries only 3 usable bits - canonical values are 0 through 7 - while the library's decode and validation functions accepted all 32 possible characters there, allowing 8, G, and R to silently decode to the identical 16-byte value as their canonical counterpart. An attacker who can submit caller-controlled ULIDs over an HTTP or API boundary can exploit this to circumvent application-layer string comparisons such as idempotency keys, deduplication guards, deny-list lookups, or audit-trail correlation, causing the server to resolve the intended record while treating the alternate spelling as a distinct key. No public exploit has been identified at time of analysis.
Dynamic Client Registration (DCR) bypass in ash_authentication_oauth2_server versions 0.1.0 through 0.3.0 allows unauthenticated network attackers to register OAuth clients on servers that were configured to require an initial access token. The root cause is a fail-open pattern in resolve_secret/3: when a configured secret provider returned nil, false, or an empty string instead of a structured :error tuple, the function wrapped the value as {:ok, value} and passed it to the bearer-token comparison, causing that comparison to succeed against any request. No public exploit code has been identified, and the vendor has released a patched version (0.3.1).
SSRF in ash_authentication_oauth2_server 0.3.0 allows an attacker who controls both an OAuth2 client's metadata URL and the associated DNS resolution to route the server's outbound CIMD metadata fetches to loopback, link-local, or internal addresses. The `public_ip?/1` guard in `AshAuthentication.Oauth2Server.CIMD.ReqFetcher` failed to classify three IPv6 address families as private - IPv4-compatible ::/96 (e.g., ::127.0.0.1), SIIT IPv4-translated ::ffff:0:0:0/96, and deprecated site-local fec0::/10 - so a crafted DNS AAAA response in any of these ranges bypassed the policy. No public exploit has been identified at time of analysis; vendor patch released in version 0.3.1.
WWW-Authenticate header parameter injection in ash_authentication_oauth2_server (versions 0.1.3 through 0.3.0) allows unauthenticated network attackers to smuggle arbitrary OAuth2 auth-params into Bearer challenge headers by supplying a tenant value containing a double-quote character. In multi-tenant Elixir/Phoenix applications that derive the Ash tenant from request-controlled data such as subdomains, Host headers, or path segments, an attacker can inject a second resource_metadata URL pointing to an attacker-controlled authorization server. Spec-compliant OAuth2 clients that follow the resource_metadata discovery URL will then contact the attacker's server instead of the legitimate one, enabling token theft or credential harvesting. No public exploit has been identified at time of analysis; a vendor-released patch is available at version 0.3.1.
Multi-tenant OAuth2 metadata cross-tenant leakage in ash_authentication_oauth2_server (versions 0.1.3 through before 0.3.1) causes shared HTTP caches to serve one tenant's RFC 8414/RFC 9728 discovery metadata - including issuer, authorization_endpoint, token_endpoint, and jwks_uri - to another tenant's clients for up to one hour. The vulnerability arises because the Phoenix ProtocolRouter sent all metadata responses with Cache-Control: public, max-age=3600 and no Vary header; when tenant identity is derived from a request header or Host (not the URL), shared caches key on URL alone, making cross-tenant cache poisoning trivially repeatable. Downstream impact extends beyond disclosure: affected clients may direct authorization codes and client secrets to the wrong tenant's token endpoint and validate tokens against the wrong JWKS keys. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
OAuth2 state-changing protocol endpoints in ash_authentication_oauth2_server (versions 0.1.0 through 0.3.0) are silently reachable under a second, unintended URL prefix (`/.well-known`) due to Phoenix's `forward` macro stripping the matched prefix before dispatch, leaving both `/oauth` and `/.well-known` mounts backed by the same ProtocolRouter route table. POST requests to `/register`, `/token`, and `/revoke` therefore answer under `/.well-known/register`, `/.well-known/token`, and `/.well-known/revoke`, bypassing any WAF rules, rate-limiting policies, or authentication exemptions scoped exclusively to the canonical `/oauth` prefix. No public exploit has been identified and the vulnerability is absent from CISA KEV; vendor patch version 0.3.1 is 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.
Open redirect in ash_typescript's TypeScript client code generator allows an attacker who controls a path-parameter value to cause a generated client to forward its request - including any credentials configured in TypedControllerConfig - to an attacker-controlled host. Affected are applications using ash_typescript 0.15.0 through 0.17.x that expose generated TypeScript clients where path parameters are user-influenced. No public exploit or CISA KEV listing is present, and the EPSS signal is correspondingly low given the niche footprint of the library.
Sensitive application data leaks from HTTP 500 responses in ash_typescript versions 0.15.0 through 0.17.x due to an ungated code path that serializes handler return values verbatim using Elixir's inspect/2. Any unauthenticated caller who can trigger a typed-controller route whose handler falls through with a non-conn term - such as {:error, %User{}} - receives the full Elixir struct inspection, potentially including hashed passwords, session tokens, and tenant identifiers, in the JSON error body. No public exploit identified at time of analysis, but the disclosure is trivially reproducible with a standard HTTP client given the right application-layer condition.
Constraint bypass in ash_typescript typed-controller routes allows remote attackers to submit argument values outside declared allowlists or bounds by exploiting a missing validation step in the Ash type pipeline. Affected versions 0.15.0 through 0.17.x call Ash.Type.cast_input/3 but never invoke Ash.Type.apply_constraints/3, leaving constraints such as one_of, max_length, min, max, and match silently unenforced at runtime. Where these constraints gate role membership, status transitions, or other security-relevant decisions in the route handler, the bypass enables privilege escalation or state-machine abuse; a vendor-released patch is available in 0.18.0. No public exploit identified at time of analysis.
Sensitive internal error data - including runtime secrets potentially carried in Ash error vars fields - leaks to unauthenticated network clients in ash_typescript 0.8.0 through 0.17.x when a configured error handler raises a FunctionClauseError on an unmatched error shape. The rescue clause in apply_error_handler/3 was intended as a safety net but fell back to returning the original, unredacted error map rather than a safe generic response, inverting the intended suppress-on-failure semantics. No public exploit code has been identified and there is no CISA KEV listing; a patched release (0.18.0) is available from the Ash Project.
FilterForm in ash_phoenix (versions 0.6.0-rc.1 through 2.3.24) exposes private relationship data to authenticated users by resolving attacker-controlled filter path parameters through private Ash relationship traversal rather than the public-only gate. By supplying crafted path or field form values targeting non-public relationships, an authenticated attacker converts query result row counts into a boolean oracle over data the resource author explicitly marked private. The CVSS 4.0 score is 2.3 (Low); no active exploitation is identified and no public proof-of-concept exists at time of analysis.
Tenant hijacking and request degradation in AshPhoenix (ash_phoenix 2.1.26 through 2.3.24) allows unauthenticated remote clients to force an Ash multi-tenant application to resolve an arbitrary tenant by supplying a crafted HTTP Host header. The root cause is that AshPhoenix.Helpers.get_subdomain/2 interpolated the configured root domain verbatim into a regex pattern, causing domain dots to act as any-character wildcards and the match to be applied unanchored and globally - so Host: foo.exampleXcom.attacker.net satisfied a rule intended to match only subdomains of example.com, returning foo as the tenant. A separate case-sensitivity flaw allowed TENANT.EXAMPLE.COM to bypass the allowlist check entirely. No CISA KEV listing and no public proof-of-concept have been identified at time of analysis, but exploitation requires no authentication and no special tooling.
Sensitive form parameters leak into server logs, crash reports, and the Phoenix development error page in ash_phoenix versions 1.2.17 through 2.3.24, where AshPhoenix.Form.Auto embeds the complete raw submitted param map verbatim into exception messages when a union sub-form receives an unrecognized _union_type value. Because the exception is raised inside library code rather than Phoenix's controller layer, the standard :filter_parameters configuration cannot redact the exposure-any field co-submitted with the union form field, including passwords and tokens, appears in plaintext in the raised message. No public exploit has been identified at time of analysis, but any user capable of submitting a form with a union field can deliberately trigger the leak regardless of intent.
Composite primary key decoding in AshAdmin (ash_admin) versions 0.1.0 through 1.3.0 can be abused by authenticated users to turn any record-lookup URL into an equality oracle over arbitrary resource attributes. By crafting a Base64+ETF-encoded payload substituting a sensitive field name (e.g., api_token, reset_token) for an actual primary key, an attacker can brute-force secret attribute values one equality guess at a time. No public exploit has been identified at time of analysis, and exploitation requires authentication and specific preconditions (CVSS 4.0: 2.3, AT:P).
AshAdmin shipped a compile-time constant string ('ash_admin-Ed55GFnX') as the default CSP nonce for inline script and style tags across all requests in versions 0.10.8 through 1.3.0, rendering nonce-based Content-Security-Policy enforcement completely ineffective for any application using the default configuration. Applications that adopted the documented default and explicitly allow-listed this published constant in their CSP script-src directive would have their CSP protection neutralized by any attacker able to inject HTML into an admin page. No active exploitation or public proof-of-concept has been identified; the CVSS 4.0 score of 2.1 reflects significant compound preconditions required for exploitation.
AshAdmin's Table, DataTable, and Show LiveView components constructed row-action URLs via raw Elixir string interpolation, splicing unencoded record primary keys directly into query strings. Attackers who control a record's string primary key - common in Ash applications using slugs or email addresses as identifiers - can craft a key containing query-string metacharacters (e.g., `legitimate-slug&action_type=destroy`) that override URL parameters when an administrator clicks a row-action link, silently redirecting them to an unintended action such as resource destruction. No public exploit code has been identified at time of analysis; exploitation requires write access to a string-keyed Ash resource and active administrator interaction, affecting ash_admin 0.3.0-rc.0 through 1.3.0.
Unfiltered exception serialization in ash_ai 0.6.0-0.x leaks internal application details - database schema, raw SQL fragments, policy module names - to authenticated chat users via the LLM conversation stream. AshAi.ToolLoop and AshAi.Tools used Elixir's Exception.message/1 verbatim to encode any raised tool exception into the tool-result payload, which the language model then relayed to the requesting user. Any authenticated user able to steer tool arguments into a code path that raises an exception could extract sensitive internal reconnaissance data; ash_ai 1.0.0 closes the gap by routing all tool exceptions through a safe formatter. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Infinite-loop denial-of-service in ash_ai's ToolLoop component (versions 0.6.0 through <1.0.0) allows an attacker who can influence LLM model output - most practically via prompt injection - to hang the agent loop indefinitely and drive unbounded, repeated model API requests. When the LLM returns tool_call_ids that are either invalid or already present in the session history, the post-filter call list empties, yet the loop recurses with a byte-identical message state, making no forward progress and wasting unbounded API budget. No public exploit code or active exploitation has been identified at time of analysis; however, the prompt-injection attack path is well within reach of applications that ingest untrusted user content.
Internal Ash attribute and argument names leak through GraphQL error responses in ash_graphql 1.9.0 through 1.10.x, bypassing application-configured error handlers intended to redact them. A logic flaw in AshGraphql.Errors causes a sanitizing error_handler's decision to suppress the :path field to be silently overridden, re-injecting raw internal field names via build_error_path/5. Unauthenticated remote clients can trigger validation failures on non-exposed or nested fields to enumerate internal schema structure that the application deliberately chose to hide. No public exploit or KEV listing exists at time of analysis.
Relay node query crash in AshGraphql (ash_graphql 0.27.0 through 1.10.x) allows an unauthenticated remote caller to abort the Absinthe node(id:...) resolver by supplying a base64-encoded relay ID whose type segment resolves to an existing BEAM VM atom that is not a registered relay resource type. Because the resolver calls Map.fetch!/2 before Absinthe's rescue handlers run, the resulting KeyError surfaces as an unhandled process exception rather than a structured GraphQL error, potentially leaking an internal stacktrace with module names and file paths. No public exploit code has been identified at time of analysis, though the fix commit is publicly visible on GitHub.
GraphQL subscription payloads carrying unauthorized record data leak to authenticated subscribers in ash_graphql 1.4.0-1.10.x due to a missing authorization filter in the batch-processing codepath of AshGraphql.Subscription.Batcher. When two or more subscription notifications arrive within the default one-second batching window, only the first is passed through the should_send?/1 authorization gate; all subsequent notifications in the same batch bypass that check entirely and are published to the subscriber's WebSocket connection. No public exploit has been identified at time of analysis, and a vendor-released patch is available in version 1.11.0.
Cross-session record leakage in ash_graphql's subscription batcher allows one subscriber's resolved GraphQL records to be delivered to a different subscriber's topic, potentially crossing tenant and actor boundaries. Versions 1.4.0 through 1.10.x are affected when the Batcher process falls back to inline `:backpressure_sync` or `:noproc` execution paths and a subscription resolver triggers a nested synchronous Ash notification in the same caller process. No public exploit has been identified at time of analysis, and a vendor-released patch is available in version 1.11.0.
Plaintext values of encrypted fields in ash_cloak leak verbatim into application logs, error-tracker payloads, changeset inspection output, and telemetry when the source attribute is not explicitly declared sensitive. All ash_cloak versions 0.1.0 through 0.3.x for the Elixir/Ash Framework are affected; a patch is available in 0.4.0. No public exploit is identified at time of analysis.
Unsafe Erlang term deserialization in ash_cloak 0.1.0-0.3.x allows an attacker who can influence encrypted column bytes to crash the BEAM runtime node via unbounded atom table exhaustion or a decompression bomb. Applications configured with Cloak's unauthenticated AES.CTR cipher are the highest-risk targets: an authenticated application user who knows their own plaintext can XOR-derive the keystream and write a forged ciphertext of equal length without the encryption key, causing the deserialization to fire on any subsequent column read. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, but the patch commit confirms two distinct, low-skill attack primitives against unpatched deployments.
Cross-tenant aggregate data leakage in ash_sql affects Elixir applications using schema-based multitenancy with strategy(:context), covering versions 0.1.0 through 0.7.0. The AshSql.AggregateQuery.add_single_aggs/5 function discards the tenant schema prefix when rebuilding outer queries for distinct aggregates, causing aggregate computations to silently read the repository default schema instead of the tenant's isolated schema. An authenticated tenant user can thereby receive aggregate values - counts, sums, or other statistics - derived from another tenant's rows, breaching the core data isolation guarantee of the multitenant deployment. No public exploit has been identified and the issue is not listed in CISA KEV.
SQL LIKE wildcard injection in ash_sql (Elixir, versions 0.1.1-rc.10 through 0.7.0) allows any user who can supply a search string to the contains/2, string_starts_with/2, or string_ends_with/2 filter functions to reintroduce live LIKE wildcards that the escape helper was intended to neutralize. The escape helper prefixes % and _ with backslash but never first escapes a backslash already present in user input, so the sequence \% survives escaping with its % intact as an unescaped wildcard, enabling attackers to widen query matches, evade negated filter guards, or crash individual queries with a trailing lone backslash. No public exploit has been identified at time of analysis, and a vendor-released fix is available in version 0.7.1.
Incorrect string trimming in ash_sql causes divergent behavior between SQL-layer and in-memory evaluation of the `string_trim/1` function, enabling users to pad string fields with tab, newline, carriage-return, or form-feed characters to bypass trimmed uniqueness or equality checks. All ash_sql versions from 0.1.0 up to (not including) 0.7.1 are affected wherever `string_trim/1` appears in Ash filters, validations, or identity constraints that are evaluated at the SQL layer. No public exploit has been identified and no active exploitation is confirmed; the overall risk is low (CVSS 4.0: 2.1), but the bypass can permit duplicate record creation or filter evasion in affected applications.
Uncontrolled recursion in ash_oban's compile-time-generated Oban worker code enables unbounded heap growth and CPU exhaustion in the BEAM worker process when a trigger's on_error action deterministically raises on the job's final attempt. Affected versions span 0.8.0-rc.1 through 0.8.13 of the ash-project/ash_oban Elixir library. Any condition that causes the on_error action to fail repeatedly - a data-layer outage, a misconfigured action, or a record the action validates and rejects - loops handle_error/4 forever, growing the process heap without bound until the BEAM runtime kills the worker. No public exploit has been identified at time of analysis; a vendor-released patch is confirmed at 0.8.14.
AshOban versions 0.2.5 through 0.8.13 expose an authorization bypass and tenant isolation break in the build_trigger/3 function, allowing any user whose input reaches the :args option to retarget update or destroy background jobs at arbitrary records - including records belonging to other tenants. The root cause is an Elixir atom-vs-string key collision: trusted job fields are stored as atom keys, user-supplied :args arrive as string keys after JSON round-tripping, Map.merge sees no collision and both survive, and JSON serialization then keeps the last (string) key when the job is persisted, causing the worker to read attacker-controlled values. No public exploit has been identified at time of analysis, though the mechanism is straightforward and fully documented by the vendor advisory GHSA-gj9p-x393-rf9h.
JSON path injection in AshSqlite (0.1.2-rc.0 through 0.2.17) allows any attacker who can supply user-controlled input to a get_path/2 query segment to read nested JSON sub-fields that the application never intended to expose. The vulnerable AshSqlite.SqlImplementation code naively concatenates user-supplied segments with periods into a SQLite json_extract path, so a segment containing a dot (e.g., 'private.secret') descends two JSON levels instead of matching a single literal key. No public exploit has been identified and the vulnerability is absent from the CISA KEV catalog; a vendor patch is available targeting version 0.2.18.
Cubic-complexity denial of service in ash_paper_trail's full-diff list change builder allows any user permitted to invoke a paper-trailed Ash action with an accepted array attribute to exhaust backend CPU and memory. Versions 0.1.1 through 0.6.x are affected; the root cause is an O(n³) list accumulation pattern in `AshPaperTrail.ChangeBuilders.FullDiff.ListChange` where unbounded action input directly drives allocation. No public exploit has been identified and the issue is not in CISA KEV, but no rate-limiting or length check guards the vulnerable path, making the attack trivially reproducible by any user with action access.
Cleartext exposure of nested sensitive fields in Ash Paper Trail audit logs (versions 0.3.0-0.6.x) allows any principal with read access to the version resource table to recover credentials, tokens, or other sensitive values stored inside embedded resources, union types, or lists. The redaction logic in `maybe_redact_changes/3` and `AshPaperTrail.Resource.Changes.CreateNewVersion` only inspects top-level resource attributes for the `sensitive?` flag, never recursing into nested structures, so a parent attribute that is not itself marked sensitive silently passes its embedded sensitive children through to the version table in cleartext. No public exploit has been identified and the issue is not listed in CISA KEV; a vendor-released patch is available at version 0.7.0.
Cleartext storage of sensitive Ash resource attributes in AshPaperTrail versions 0.1.1 through 0.6.x allows any actor with read access to the generated version resource to recover plaintext values of fields marked `sensitive? true`. The library's `CreateVersionResource` transformer incorrectly derives the sensitivity flag for the `changes` map from the `ignore_attributes` exclusion list rather than from the actual tracked attributes, causing the map to always be declared `sensitive? false` and `public? true`, which bypasses Ash's built-in redaction and exposes sensitive values in API responses, logs, and inspect output. No public exploit is identified and no active exploitation is confirmed; a vendor patch was released in version 0.7.0.
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.
Sensitive field disclosure in ash_lua (versions 0.1.0 through 0.2.0) allows any actor who can submit a Lua script to read Ash resource attributes that are deliberately excluded from the manifest's exposed-field allow-list - including sensitive?: true columns such as hashed passwords. The operation aggregate path in AshLua.Runtime resolved field names directly via String.to_existing_atom and Ash.Query.Aggregate.new! without invoking the same AshLua.Fields.for_action/4 allow-list check enforced by the normal field-read path, creating an alternate route to private data. Vendor patch 0.2.1 is confirmed available; no CISA KEV listing or independent exploit beyond the PoC embedded in the security advisory has been identified.
Unauthenticated resource exhaustion in ash_authentication_oauth2_server 0.3.0 enables any remote attacker to grow database storage and heap memory without bound when the Client ID Metadata Document (CIMD) feature is enabled. The /authorize endpoint's resolve_client/3 function fetches and permanently upserts one database row per distinct URL-shaped client_id, with no row cap, no TTL-based expiry, and no field-length limit; additionally, fetched documents enter CIMD.Cache before validation, meaning even rejected documents consume cache memory until their TTL expires. No public exploit code or active exploitation has been identified at time of analysis.
Unauthenticated atom table exhaustion in ash_typescript 0.1.0-0.17.x allows any network attacker to crash the entire Erlang/BEAM node by submitting RPC requests with attacker-controlled field names. The library's `convert_to_field_atom/2` function calls `String.to_atom/1` on client-supplied strings without validation, minting permanent, non-garbage-collected atoms until the VM hits its table limit and aborts. Additionally, field names exceeding 255 characters trigger an uncaught `SystemLimitError`. No public exploit is identified at time of analysis, but exploitation is trivial given no authentication or special configuration is required.
Field policy enforcement in ash_typescript RPC serialization is bypassed by a missing pattern-match clause, allowing unauthenticated remote callers to receive the real values of attributes that Ash field policies explicitly denied. Any action returning an embedded resource through the RPC layer exposes policy-protected fields - including sensitive PII such as SSNs, as demonstrated in the patch test suite - inside the serialized JSON response. Affects ash_typescript 0.11.0 through 0.17.x; no public exploit code exists at time of analysis, but the attack path is fully described in the vendor advisory and the two-line fix diff.
Unauthenticated BEAM atom table exhaustion in ash_typescript 0.11.0-0.17.x allows a remote attacker to abort the Erlang VM and take down the entire application node by sending RPC requests carrying many distinct, unrecognized field names targeting a typed struct field selector. The root cause is `resolve_typed_struct_field/2` calling `String.to_atom/1` on unresolvable client input before any field-existence validation, permanently minting atoms that the BEAM runtime never reclaims. A vendor-released patch is available in 0.18.0; no public exploit code or CISA KEV listing exists at time of analysis.
Tenant authorization bypass in ash_phoenix's SubdomainHook allows an authenticated user to cross tenant boundaries and access or modify data belonging to other tenants. The flaw is rooted in a LiveView lifecycle ordering error: AshPhoenix.LiveView.SubdomainHook.on_mount/4 called the consumer-defined authorization callback before Phoenix LiveView's handle_params phase had run, guaranteeing the callback always received a nil tenant and either crashed or silently permitted the request. Critically, the flawed check was never re-evaluated on subsequent in-session navigations, so the bypass persisted for the lifetime of the LiveView connection. No public exploit has been identified at time of analysis, but the bypass is systematic and total for all affected deployments using SubdomainHook with tenant-scoped authorization callbacks.
Arbitrary file write via path traversal in AshAdmin's file upload handler affects versions 0.13.7 through 1.3.0, enabling any authenticated admin user to write attacker-controlled bytes to any filesystem path writable by the BEAM process. The root cause is that browser-supplied filenames are concatenated into upload paths via Elixir's Path.join/1 without stripping directory components, so a crafted filename such as ../../../../var/www/app/priv/static/evil.ex escapes the randomized temp directory. No public exploit has been identified at time of analysis, but the primitive directly enables remote code execution by overwriting application modules, static assets, cron jobs, or SSH authorized_keys files.
Stored XSS in ash_admin's relationship typeahead components allows an attacker with low-privilege record-creation access to execute arbitrary JavaScript in an administrator's browser. Affected are ash_admin versions 0.13.0 through 1.3.1, where the `RelationshipField` and `ManagedRelationshipSelectField` components render database record label fields unescaped via `Phoenix.HTML.raw/1` after applying search-term highlight markup. A crafted label such as `<img src=x onerror=...>` persists in the database and fires whenever an admin's typeahead dropdown displays the matching record, granting the attacker full admin-level privileges over everything AshAdmin exposes. No public exploit code has been identified at time of analysis; a vendor-released patch is available in version 1.3.1.
Atom table exhaustion in ash_admin's Phoenix LiveView event handlers allows any authenticated user reaching the admin interface to crash the entire BEAM VM node. Two handlers - AshAdmin.PageLive's set_actor and AshAdmin.Components.Resource.Show's calculate - passed unvalidated client strings directly to Module.concat/1 and String.to_atom/1 respectively, minting a permanent new atom per unique request. Because BEAM atoms are never garbage collected and the table is capped at roughly one million entries, flooding either handler terminates the VM and takes down every Elixir application co-hosted on the node. No active exploitation has been confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; patch version 1.3.1 is available.
Cookie shadowing via unanchored regex in AshAdmin (versions 0.9.1-1.3.0) allows an attacker who controls a sibling subdomain to inject state cookies that rebind an administrator's LiveSocket session to an arbitrary actor, tenant, or authorization mode - effectively bypassing the admin panel's authorization controls. The client-side JavaScript cookie parser used `new RegExp(name + "=([^;]+)")`, which matches any cookie whose name merely ends with the target name, enabling a shadowing cookie (e.g., `xactor_authorizing` over `actor_authorizing`) set from a sibling subdomain with `Domain=.example.com` to silently win. No public exploit or CISA KEV listing exists at time of analysis, but the integrity impact is high for any multi-subdomain deployment.
Credential leakage in ash_ai (versions 0.1.0 through before 1.0.0) exposes embedding provider API keys and request internals to authenticated API callers via unsanitized error messages. In AshAi.Changes.Vectorize, a failed embedding provider call caused the raw Elixir error struct - which HTTP clients commonly populate with the outbound Authorization header, request URL, and provider response body - to be passed through inspect/1 directly into a user-facing changeset error. AshJsonApi and AshGraphql serialize these changeset errors into API responses, making the full credential material readable by any caller who can trigger a provider failure. No public exploit has been identified at time of analysis, but the trigger condition (oversized or malformed vectorized content) is trivially reachable by any authenticated user of an exposed endpoint.
Authorization bypass in AshAi (ash_ai) versions 0.6.0 through pre-1.0.0 allows any authenticated tool caller to update or destroy database records it never legitimately identified, up to and including every row in a table. The flaw is in AshAi.Tool.Execution.identity_filter/3, which passes raw tool arguments directly into Ash.Query.do_filter/2; because Ash's filter DSL interprets map values as predicate expressions rather than scalar literals, a caller can inject filter logic such as {"not_eq": "<own-ref>"} to retarget bulk writes to arbitrary records. A vendor patch is available in commit 87f616d and the fix version is 1.0.0; no public exploit or CISA KEV listing exists at time of analysis.
DNS-rebinding protection in AshAi.Mcp.Server (ash_ai 0.8.0-0.x) is bypassable because the default origin check trusts the attacker-controlled Host and X-Forwarded-Proto headers as proxies for TLS context. A malicious web page can exploit this to issue arbitrary cross-site requests to the victim's locally running MCP server, executing MCP calls under the victim's actor credentials. No public exploit has been identified at time of analysis, but the attack path is mechanically straightforward for any attacker who can lure a developer to a malicious page while they have the MCP server running locally.
Remote code execution in ash_ai (versions 0.1.0 through pre-1.0.0) allows unauthenticated network attackers to execute arbitrary Elixir code on the server by submitting EEx template payloads through prompt action arguments. The AshAi.Actions.Prompt module incorrectly passed function-supplied prompt content - which is frequently assembled from user-controlled action arguments - through EEx.eval_string/2 before forwarding to the AI model, meaning payloads like <%= System.cmd("id", []) %> execute server-side with application process privileges. No public exploit code or CISA KEV listing exists at time of analysis, but the zero-authentication, single-request exploitation path gives this a higher operational priority than the EPSS percentile alone suggests.
Cross-tenant data disclosure in ash_graphql affects authenticated subscribers in multi-tenant deployments running versions 1.4.0 through 1.10.x. The subscription resolver's in-memory authorization fast path evaluates read policy filters without any tenant condition, allowing a subscriber scoped to tenant A to receive GraphQL subscription notifications carrying tenant B's records. The single-notification code path had no tenant guard at all, and the batched path checked tenant only on the list head, leaving all subsequent entries to authorize purely in memory without tenancy enforcement. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the impact is high confidentiality loss for any multi-tenant SaaS product built on this stack.
AshGraphql's Absinthe complexity calculator undercounts nested Relay connection and keyset pagination queries, allowing unauthenticated clients to bypass any configured `max_complexity` cap and force unbounded database reads. Versions 0.16.23 through 1.10.x expose this flaw whenever a schema uses `first`/`last`-based pagination: a single crafted query such as `posts(first: 500) { edges { node { comments(first: 500) { ... } } } }` scores near-zero in Absinthe's guard while materializing up to 250,000 records per request. No active exploitation is confirmed (no CISA KEV listing), but the attack requires no authentication and is trivially constructable from the public advisory description alone.
Silent schema cross-contamination in ash_postgres multi-tenancy allows a low-privileged user who can trigger a tenant rename to gain unauthorized read and write access to a different tenant's PostgreSQL schema. Affected versions span 0.25.0 through 2.13.0 of the ash-project/ash_postgres Elixir library. When PostgreSQL rejects the ALTER SCHEMA rename due to a name collision, the library silently reports success, causing the tenant metadata row to be committed pointing at the victim's live schema - routing all subsequent reads and writes for the attacker's tenant against the victim's data. No public exploit code or CISA KEV listing has been identified at time of analysis.
Field policy bypass in AshLua 0.1.0-0.2.1 allows authenticated Lua script executors to read actor-restricted fields by requesting them through aggregate operations (min, max, first, sum, avg, list) rather than as direct record fields, circumventing per-actor field policy authorization while remaining within the configured exposed-field allow-list. The Ash framework normally redacts forbidden fields on returned record structs with %Ash.ForbiddenField{}, but AshLua's read action did not apply this check when constructing ad-hoc Ash.Query.Aggregate instances, returning raw field values instead. No public exploit code exists and the vulnerability is not in CISA KEV; the CVSS 4.0 score of 6.0 reflects network-accessible but prerequisite-gated exploitation requiring authenticated script execution access.
Field policy bypass in ash_ai (versions 0.1.0 through < 1.0.3) allows authenticated, low-privilege actors to read per-actor-restricted fields - including sensitive PII - by invoking the aggregate result type (min, max, sum, avg) via the LLM read tool instead of direct record retrieval. Ash field policies redact forbidden fields on returned records by substituting %Ash.ForbiddenField{}, but this redaction mechanism was never applied to aggregate code paths; the tool's authorization check only tested field.public?, a static attribute orthogonal to per-actor policy evaluation. Patch version 1.0.3 is available via the vendor advisory; no CISA KEV listing or public exploit code has been identified at time of analysis.
Terminal escape sequence injection in ash-project/usage_rules (versions 0.1.18 through 1.2.7) allows a malicious Hex package publisher to forge what developers see when running mix usage_rules.search_docs. The Mix task queries search.hexdocs.pm and renders publisher-controlled fields - title, package name, type, doc reference, and highlighted snippets - verbatim to the terminal with no control-character sanitization, only adding ANSI highlighting rather than stripping injected sequences. A package author who embeds ANSI cursor-movement, line-erase, carriage-return, or OSC 52 clipboard-write sequences in their documentation can cause a developer's terminal to display a forged hexdocs URL, conceal output, or silently write an attacker-controlled command to the clipboard; no public exploit has been identified at time of analysis.
Terminal escape sequence injection in ash-project Igniter (versions 0.8.1-0.8.3) allows a malicious or typosquatted hex.pm package publisher to forge the `mix igniter.install` confirmation panel by embedding ANSI cursor-movement and line-erase control sequences in publisher-controlled metadata fields such as the package description, owner usernames, version, and download counts. Developers relying on this panel as an anti-typosquatting safeguard are shown attacker-crafted content that conceals the real metadata, potentially deceiving them into approving a malicious dependency. A vendor patch is available in version 0.8.4; no public exploit and no CISA KEV listing have been identified at time of analysis.
ULID first-character non-canonicality in ash_double_entry (Elixir) exposes a multi-spelling identifier aliasing flaw affecting versions 0.1.0 through 1.0.18. The AshDoubleEntry.ULID type encodes 128-bit identifiers as 26 Crockford base-32 characters, but the first character carries only 3 usable bits - canonical values are 0 through 7 - while the library's decode and validation functions accepted all 32 possible characters there, allowing 8, G, and R to silently decode to the identical 16-byte value as their canonical counterpart. An attacker who can submit caller-controlled ULIDs over an HTTP or API boundary can exploit this to circumvent application-layer string comparisons such as idempotency keys, deduplication guards, deny-list lookups, or audit-trail correlation, causing the server to resolve the intended record while treating the alternate spelling as a distinct key. No public exploit has been identified at time of analysis.
Dynamic Client Registration (DCR) bypass in ash_authentication_oauth2_server versions 0.1.0 through 0.3.0 allows unauthenticated network attackers to register OAuth clients on servers that were configured to require an initial access token. The root cause is a fail-open pattern in resolve_secret/3: when a configured secret provider returned nil, false, or an empty string instead of a structured :error tuple, the function wrapped the value as {:ok, value} and passed it to the bearer-token comparison, causing that comparison to succeed against any request. No public exploit code has been identified, and the vendor has released a patched version (0.3.1).
SSRF in ash_authentication_oauth2_server 0.3.0 allows an attacker who controls both an OAuth2 client's metadata URL and the associated DNS resolution to route the server's outbound CIMD metadata fetches to loopback, link-local, or internal addresses. The `public_ip?/1` guard in `AshAuthentication.Oauth2Server.CIMD.ReqFetcher` failed to classify three IPv6 address families as private - IPv4-compatible ::/96 (e.g., ::127.0.0.1), SIIT IPv4-translated ::ffff:0:0:0/96, and deprecated site-local fec0::/10 - so a crafted DNS AAAA response in any of these ranges bypassed the policy. No public exploit has been identified at time of analysis; vendor patch released in version 0.3.1.
WWW-Authenticate header parameter injection in ash_authentication_oauth2_server (versions 0.1.3 through 0.3.0) allows unauthenticated network attackers to smuggle arbitrary OAuth2 auth-params into Bearer challenge headers by supplying a tenant value containing a double-quote character. In multi-tenant Elixir/Phoenix applications that derive the Ash tenant from request-controlled data such as subdomains, Host headers, or path segments, an attacker can inject a second resource_metadata URL pointing to an attacker-controlled authorization server. Spec-compliant OAuth2 clients that follow the resource_metadata discovery URL will then contact the attacker's server instead of the legitimate one, enabling token theft or credential harvesting. No public exploit has been identified at time of analysis; a vendor-released patch is available at version 0.3.1.
Multi-tenant OAuth2 metadata cross-tenant leakage in ash_authentication_oauth2_server (versions 0.1.3 through before 0.3.1) causes shared HTTP caches to serve one tenant's RFC 8414/RFC 9728 discovery metadata - including issuer, authorization_endpoint, token_endpoint, and jwks_uri - to another tenant's clients for up to one hour. The vulnerability arises because the Phoenix ProtocolRouter sent all metadata responses with Cache-Control: public, max-age=3600 and no Vary header; when tenant identity is derived from a request header or Host (not the URL), shared caches key on URL alone, making cross-tenant cache poisoning trivially repeatable. Downstream impact extends beyond disclosure: affected clients may direct authorization codes and client secrets to the wrong tenant's token endpoint and validate tokens against the wrong JWKS keys. No public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
OAuth2 state-changing protocol endpoints in ash_authentication_oauth2_server (versions 0.1.0 through 0.3.0) are silently reachable under a second, unintended URL prefix (`/.well-known`) due to Phoenix's `forward` macro stripping the matched prefix before dispatch, leaving both `/oauth` and `/.well-known` mounts backed by the same ProtocolRouter route table. POST requests to `/register`, `/token`, and `/revoke` therefore answer under `/.well-known/register`, `/.well-known/token`, and `/.well-known/revoke`, bypassing any WAF rules, rate-limiting policies, or authentication exemptions scoped exclusively to the canonical `/oauth` prefix. No public exploit has been identified and the vulnerability is absent from CISA KEV; vendor patch version 0.3.1 is 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.
Open redirect in ash_typescript's TypeScript client code generator allows an attacker who controls a path-parameter value to cause a generated client to forward its request - including any credentials configured in TypedControllerConfig - to an attacker-controlled host. Affected are applications using ash_typescript 0.15.0 through 0.17.x that expose generated TypeScript clients where path parameters are user-influenced. No public exploit or CISA KEV listing is present, and the EPSS signal is correspondingly low given the niche footprint of the library.
Sensitive application data leaks from HTTP 500 responses in ash_typescript versions 0.15.0 through 0.17.x due to an ungated code path that serializes handler return values verbatim using Elixir's inspect/2. Any unauthenticated caller who can trigger a typed-controller route whose handler falls through with a non-conn term - such as {:error, %User{}} - receives the full Elixir struct inspection, potentially including hashed passwords, session tokens, and tenant identifiers, in the JSON error body. No public exploit identified at time of analysis, but the disclosure is trivially reproducible with a standard HTTP client given the right application-layer condition.
Constraint bypass in ash_typescript typed-controller routes allows remote attackers to submit argument values outside declared allowlists or bounds by exploiting a missing validation step in the Ash type pipeline. Affected versions 0.15.0 through 0.17.x call Ash.Type.cast_input/3 but never invoke Ash.Type.apply_constraints/3, leaving constraints such as one_of, max_length, min, max, and match silently unenforced at runtime. Where these constraints gate role membership, status transitions, or other security-relevant decisions in the route handler, the bypass enables privilege escalation or state-machine abuse; a vendor-released patch is available in 0.18.0. No public exploit identified at time of analysis.
Sensitive internal error data - including runtime secrets potentially carried in Ash error vars fields - leaks to unauthenticated network clients in ash_typescript 0.8.0 through 0.17.x when a configured error handler raises a FunctionClauseError on an unmatched error shape. The rescue clause in apply_error_handler/3 was intended as a safety net but fell back to returning the original, unredacted error map rather than a safe generic response, inverting the intended suppress-on-failure semantics. No public exploit code has been identified and there is no CISA KEV listing; a patched release (0.18.0) is available from the Ash Project.
FilterForm in ash_phoenix (versions 0.6.0-rc.1 through 2.3.24) exposes private relationship data to authenticated users by resolving attacker-controlled filter path parameters through private Ash relationship traversal rather than the public-only gate. By supplying crafted path or field form values targeting non-public relationships, an authenticated attacker converts query result row counts into a boolean oracle over data the resource author explicitly marked private. The CVSS 4.0 score is 2.3 (Low); no active exploitation is identified and no public proof-of-concept exists at time of analysis.
Tenant hijacking and request degradation in AshPhoenix (ash_phoenix 2.1.26 through 2.3.24) allows unauthenticated remote clients to force an Ash multi-tenant application to resolve an arbitrary tenant by supplying a crafted HTTP Host header. The root cause is that AshPhoenix.Helpers.get_subdomain/2 interpolated the configured root domain verbatim into a regex pattern, causing domain dots to act as any-character wildcards and the match to be applied unanchored and globally - so Host: foo.exampleXcom.attacker.net satisfied a rule intended to match only subdomains of example.com, returning foo as the tenant. A separate case-sensitivity flaw allowed TENANT.EXAMPLE.COM to bypass the allowlist check entirely. No CISA KEV listing and no public proof-of-concept have been identified at time of analysis, but exploitation requires no authentication and no special tooling.
Sensitive form parameters leak into server logs, crash reports, and the Phoenix development error page in ash_phoenix versions 1.2.17 through 2.3.24, where AshPhoenix.Form.Auto embeds the complete raw submitted param map verbatim into exception messages when a union sub-form receives an unrecognized _union_type value. Because the exception is raised inside library code rather than Phoenix's controller layer, the standard :filter_parameters configuration cannot redact the exposure-any field co-submitted with the union form field, including passwords and tokens, appears in plaintext in the raised message. No public exploit has been identified at time of analysis, but any user capable of submitting a form with a union field can deliberately trigger the leak regardless of intent.
Composite primary key decoding in AshAdmin (ash_admin) versions 0.1.0 through 1.3.0 can be abused by authenticated users to turn any record-lookup URL into an equality oracle over arbitrary resource attributes. By crafting a Base64+ETF-encoded payload substituting a sensitive field name (e.g., api_token, reset_token) for an actual primary key, an attacker can brute-force secret attribute values one equality guess at a time. No public exploit has been identified at time of analysis, and exploitation requires authentication and specific preconditions (CVSS 4.0: 2.3, AT:P).
AshAdmin shipped a compile-time constant string ('ash_admin-Ed55GFnX') as the default CSP nonce for inline script and style tags across all requests in versions 0.10.8 through 1.3.0, rendering nonce-based Content-Security-Policy enforcement completely ineffective for any application using the default configuration. Applications that adopted the documented default and explicitly allow-listed this published constant in their CSP script-src directive would have their CSP protection neutralized by any attacker able to inject HTML into an admin page. No active exploitation or public proof-of-concept has been identified; the CVSS 4.0 score of 2.1 reflects significant compound preconditions required for exploitation.
AshAdmin's Table, DataTable, and Show LiveView components constructed row-action URLs via raw Elixir string interpolation, splicing unencoded record primary keys directly into query strings. Attackers who control a record's string primary key - common in Ash applications using slugs or email addresses as identifiers - can craft a key containing query-string metacharacters (e.g., `legitimate-slug&action_type=destroy`) that override URL parameters when an administrator clicks a row-action link, silently redirecting them to an unintended action such as resource destruction. No public exploit code has been identified at time of analysis; exploitation requires write access to a string-keyed Ash resource and active administrator interaction, affecting ash_admin 0.3.0-rc.0 through 1.3.0.
Unfiltered exception serialization in ash_ai 0.6.0-0.x leaks internal application details - database schema, raw SQL fragments, policy module names - to authenticated chat users via the LLM conversation stream. AshAi.ToolLoop and AshAi.Tools used Elixir's Exception.message/1 verbatim to encode any raised tool exception into the tool-result payload, which the language model then relayed to the requesting user. Any authenticated user able to steer tool arguments into a code path that raises an exception could extract sensitive internal reconnaissance data; ash_ai 1.0.0 closes the gap by routing all tool exceptions through a safe formatter. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Infinite-loop denial-of-service in ash_ai's ToolLoop component (versions 0.6.0 through <1.0.0) allows an attacker who can influence LLM model output - most practically via prompt injection - to hang the agent loop indefinitely and drive unbounded, repeated model API requests. When the LLM returns tool_call_ids that are either invalid or already present in the session history, the post-filter call list empties, yet the loop recurses with a byte-identical message state, making no forward progress and wasting unbounded API budget. No public exploit code or active exploitation has been identified at time of analysis; however, the prompt-injection attack path is well within reach of applications that ingest untrusted user content.
Internal Ash attribute and argument names leak through GraphQL error responses in ash_graphql 1.9.0 through 1.10.x, bypassing application-configured error handlers intended to redact them. A logic flaw in AshGraphql.Errors causes a sanitizing error_handler's decision to suppress the :path field to be silently overridden, re-injecting raw internal field names via build_error_path/5. Unauthenticated remote clients can trigger validation failures on non-exposed or nested fields to enumerate internal schema structure that the application deliberately chose to hide. No public exploit or KEV listing exists at time of analysis.
Relay node query crash in AshGraphql (ash_graphql 0.27.0 through 1.10.x) allows an unauthenticated remote caller to abort the Absinthe node(id:...) resolver by supplying a base64-encoded relay ID whose type segment resolves to an existing BEAM VM atom that is not a registered relay resource type. Because the resolver calls Map.fetch!/2 before Absinthe's rescue handlers run, the resulting KeyError surfaces as an unhandled process exception rather than a structured GraphQL error, potentially leaking an internal stacktrace with module names and file paths. No public exploit code has been identified at time of analysis, though the fix commit is publicly visible on GitHub.
GraphQL subscription payloads carrying unauthorized record data leak to authenticated subscribers in ash_graphql 1.4.0-1.10.x due to a missing authorization filter in the batch-processing codepath of AshGraphql.Subscription.Batcher. When two or more subscription notifications arrive within the default one-second batching window, only the first is passed through the should_send?/1 authorization gate; all subsequent notifications in the same batch bypass that check entirely and are published to the subscriber's WebSocket connection. No public exploit has been identified at time of analysis, and a vendor-released patch is available in version 1.11.0.
Cross-session record leakage in ash_graphql's subscription batcher allows one subscriber's resolved GraphQL records to be delivered to a different subscriber's topic, potentially crossing tenant and actor boundaries. Versions 1.4.0 through 1.10.x are affected when the Batcher process falls back to inline `:backpressure_sync` or `:noproc` execution paths and a subscription resolver triggers a nested synchronous Ash notification in the same caller process. No public exploit has been identified at time of analysis, and a vendor-released patch is available in version 1.11.0.
Plaintext values of encrypted fields in ash_cloak leak verbatim into application logs, error-tracker payloads, changeset inspection output, and telemetry when the source attribute is not explicitly declared sensitive. All ash_cloak versions 0.1.0 through 0.3.x for the Elixir/Ash Framework are affected; a patch is available in 0.4.0. No public exploit is identified at time of analysis.
Unsafe Erlang term deserialization in ash_cloak 0.1.0-0.3.x allows an attacker who can influence encrypted column bytes to crash the BEAM runtime node via unbounded atom table exhaustion or a decompression bomb. Applications configured with Cloak's unauthenticated AES.CTR cipher are the highest-risk targets: an authenticated application user who knows their own plaintext can XOR-derive the keystream and write a forged ciphertext of equal length without the encryption key, causing the deserialization to fire on any subsequent column read. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in CISA KEV, but the patch commit confirms two distinct, low-skill attack primitives against unpatched deployments.
Cross-tenant aggregate data leakage in ash_sql affects Elixir applications using schema-based multitenancy with strategy(:context), covering versions 0.1.0 through 0.7.0. The AshSql.AggregateQuery.add_single_aggs/5 function discards the tenant schema prefix when rebuilding outer queries for distinct aggregates, causing aggregate computations to silently read the repository default schema instead of the tenant's isolated schema. An authenticated tenant user can thereby receive aggregate values - counts, sums, or other statistics - derived from another tenant's rows, breaching the core data isolation guarantee of the multitenant deployment. No public exploit has been identified and the issue is not listed in CISA KEV.
SQL LIKE wildcard injection in ash_sql (Elixir, versions 0.1.1-rc.10 through 0.7.0) allows any user who can supply a search string to the contains/2, string_starts_with/2, or string_ends_with/2 filter functions to reintroduce live LIKE wildcards that the escape helper was intended to neutralize. The escape helper prefixes % and _ with backslash but never first escapes a backslash already present in user input, so the sequence \% survives escaping with its % intact as an unescaped wildcard, enabling attackers to widen query matches, evade negated filter guards, or crash individual queries with a trailing lone backslash. No public exploit has been identified at time of analysis, and a vendor-released fix is available in version 0.7.1.
Incorrect string trimming in ash_sql causes divergent behavior between SQL-layer and in-memory evaluation of the `string_trim/1` function, enabling users to pad string fields with tab, newline, carriage-return, or form-feed characters to bypass trimmed uniqueness or equality checks. All ash_sql versions from 0.1.0 up to (not including) 0.7.1 are affected wherever `string_trim/1` appears in Ash filters, validations, or identity constraints that are evaluated at the SQL layer. No public exploit has been identified and no active exploitation is confirmed; the overall risk is low (CVSS 4.0: 2.1), but the bypass can permit duplicate record creation or filter evasion in affected applications.
Uncontrolled recursion in ash_oban's compile-time-generated Oban worker code enables unbounded heap growth and CPU exhaustion in the BEAM worker process when a trigger's on_error action deterministically raises on the job's final attempt. Affected versions span 0.8.0-rc.1 through 0.8.13 of the ash-project/ash_oban Elixir library. Any condition that causes the on_error action to fail repeatedly - a data-layer outage, a misconfigured action, or a record the action validates and rejects - loops handle_error/4 forever, growing the process heap without bound until the BEAM runtime kills the worker. No public exploit has been identified at time of analysis; a vendor-released patch is confirmed at 0.8.14.
AshOban versions 0.2.5 through 0.8.13 expose an authorization bypass and tenant isolation break in the build_trigger/3 function, allowing any user whose input reaches the :args option to retarget update or destroy background jobs at arbitrary records - including records belonging to other tenants. The root cause is an Elixir atom-vs-string key collision: trusted job fields are stored as atom keys, user-supplied :args arrive as string keys after JSON round-tripping, Map.merge sees no collision and both survive, and JSON serialization then keeps the last (string) key when the job is persisted, causing the worker to read attacker-controlled values. No public exploit has been identified at time of analysis, though the mechanism is straightforward and fully documented by the vendor advisory GHSA-gj9p-x393-rf9h.
JSON path injection in AshSqlite (0.1.2-rc.0 through 0.2.17) allows any attacker who can supply user-controlled input to a get_path/2 query segment to read nested JSON sub-fields that the application never intended to expose. The vulnerable AshSqlite.SqlImplementation code naively concatenates user-supplied segments with periods into a SQLite json_extract path, so a segment containing a dot (e.g., 'private.secret') descends two JSON levels instead of matching a single literal key. No public exploit has been identified and the vulnerability is absent from the CISA KEV catalog; a vendor patch is available targeting version 0.2.18.
Cubic-complexity denial of service in ash_paper_trail's full-diff list change builder allows any user permitted to invoke a paper-trailed Ash action with an accepted array attribute to exhaust backend CPU and memory. Versions 0.1.1 through 0.6.x are affected; the root cause is an O(n³) list accumulation pattern in `AshPaperTrail.ChangeBuilders.FullDiff.ListChange` where unbounded action input directly drives allocation. No public exploit has been identified and the issue is not in CISA KEV, but no rate-limiting or length check guards the vulnerable path, making the attack trivially reproducible by any user with action access.
Cleartext exposure of nested sensitive fields in Ash Paper Trail audit logs (versions 0.3.0-0.6.x) allows any principal with read access to the version resource table to recover credentials, tokens, or other sensitive values stored inside embedded resources, union types, or lists. The redaction logic in `maybe_redact_changes/3` and `AshPaperTrail.Resource.Changes.CreateNewVersion` only inspects top-level resource attributes for the `sensitive?` flag, never recursing into nested structures, so a parent attribute that is not itself marked sensitive silently passes its embedded sensitive children through to the version table in cleartext. No public exploit has been identified and the issue is not listed in CISA KEV; a vendor-released patch is available at version 0.7.0.
Cleartext storage of sensitive Ash resource attributes in AshPaperTrail versions 0.1.1 through 0.6.x allows any actor with read access to the generated version resource to recover plaintext values of fields marked `sensitive? true`. The library's `CreateVersionResource` transformer incorrectly derives the sensitivity flag for the `changes` map from the `ignore_attributes` exclusion list rather than from the actual tracked attributes, causing the map to always be declared `sensitive? false` and `public? true`, which bypasses Ash's built-in redaction and exposes sensitive values in API responses, logs, and inspect output. No public exploit is identified and no active exploitation is confirmed; a vendor patch was released in version 0.7.0.
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.