CVE-2026-105283 is a vulnerability in ash-project's ash_typescript component that allows unauthenticated attackers to obtain sensitive internal Elixir terms from RPC error responses. This occurs because certain error cases are rendered without redaction, exposing internal data in client-facing error messages. The issue affects versions from 0.1.0 up to but not including 0.19.1.
Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via Ash.count/2, Ash.exists/2 and Ash.aggregate/3.
Ash.Actions.Aggregate.run/4 (lib/ash/actions/aggregate.ex) applied only the root resource's read policy before running the aggregate query. The read path also applies each related resource's read policy to filter and sort references that cross a relationship, directly (for example comments.body) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through Ash.Query.filter_input/2, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. Ash.read/2 and its page counts are not affected.
This issue affects ash: from 2.6.0 before 3.34.6.
CVE-2026-94201 is a high-severity vulnerability in the ash-project's ash library affecting versions from 3.5.1 up to but not including 3.34.3. It arises from unsafe handling of :atom-typed attributes with the unsafe_to_atom? constraint set to true, leading to unbounded atom table growth when attacker-controlled filter values are used. This can exhaust the BEAM atom table and crash the node, causing a denial of service. The issue is fixed by adding a coercion method that avoids interning new atoms during filtering comparisons.
Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.
Action arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.set_private_argument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.
Ash.Actions.Destroy.Bulk.base_changeset/5 and Ash.Actions.Update.Bulk.base_changeset/5 match every key in the caller-supplied parameter map against all of the action's arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulk_destroy/4 or Ash.bulk_update/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action's changes or validations. Depending on how the application uses the argument (for example an acting_user_id driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.
The fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :private_arguments option.
This issue affects ash: from 2.17.15 before 3.33.11.
Ash field_policies are documented to protect against filter-based information disclosure: when a field the actor may not see is referenced in a filter, it is replaced with an expression that evaluates to nil, so a filter cannot be used as a yes/no oracle to read a value the actor cannot see.
This nilling was applied to attributes but not to calculations or aggregates. A user-supplied filter reference to a calculation or aggregate carries an Ash.Query.Calculation / Ash.Query.Aggregate struct, which the authorizer's reference replacement did not match (it only matched the Ash.Resource.* structs), so the filter ran against the real value.
As a result, an actor whose field policies forbid a calculation or aggregate can still filter by it (for example filter(secret_calc == "x") or filter(comment_count == n)) and learn the value from whether rows match — an oracle that recovers field-policy-protected values one probe at a time. Filtering is commonly exposed to lower-privileged actors (for example via AshGraphql or AshJsonApi filter arguments), which is exactly the surface field policies are meant to protect.
The fix routes filter references to calculations and aggregates through the same field-policy nilling as attributes.
This issue affects ash: from 2.11.0-rc.0 before 3.33.4.
AshLua exposes Ash read actions to Lua scripts run through an eval action. A read call accepts an operation (list, min, max, first, sum, avg) that builds an ad-hoc Ash.Query.Aggregate over a named field and returns its raw value.
Ash field policies redact forbidden fields on returned records (replacing them with %Ash.ForbiddenField{}), but that redaction does not apply to aggregate values. A script could therefore read a field the calling actor's field policies forbid by requesting it as an aggregate instead of as a field. This includes fields that are public? true but restricted per-actor by a field policy, such as sensitive PII. The prior hardening only enforced the exposed-field allow-list (field visibility), which is a separate axis from per-actor field-policy authorization.
The fix authorizes the aggregated field against the resource's field policies, so aggregating over a field the actor may not see is refused or scoped to the rows where it is visible.
This issue affects ash_lua: from 0.1.0 before 0.2.2.
AshAi exposes Ash read actions to language-model tool calls. The read tool accepts an aggregate result type (min, max, sum, avg) that builds an ad-hoc Ash.Query.Aggregate over a named field and returns its raw value.
Ash field policies redact forbidden fields on returned records (replacing them with %Ash.ForbiddenField{}), but that redaction does not apply to aggregate values. A tool caller could therefore read a field the calling actor's field policies forbid by requesting it as an aggregate; min/max in particular return an actual field value. This includes fields that are public? true but restricted per-actor by a field policy, such as sensitive PII. The tool's existing check only required the field to be public, which is a separate axis from per-actor field-policy authorization.
The fix authorizes the aggregated field against the resource's field policies, so aggregating over a field the actor may not see is refused or scoped to the rows where it is visible.
This issue affects ash_ai: from 0.1.0 before 1.0.3.
Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in ash-project usage_rules allows a malicious package publisher to inject terminal control sequences into the output of mix usage_rules.search_docs.
mix usage_rules.search_docs searches Hex documentation through search.hexdocs.pm, which indexes the documentation of every published package, and prints the matching results (title, package, type, doc reference, and highlighted snippets) to the terminal. The formatter in Mix.Tasks.UsageRules.SearchDocs interpolated those publisher-controlled fields verbatim, neutralizing no terminal control characters; the only transform it applied adds escape sequences rather than removing them. A malicious package can embed ANSI terminal escape sequences (cursor movement, line erase, carriage returns, OSC 52 clipboard writes) in its indexed documentation, so when a developer runs a search that surfaces those docs the sequences reach the terminal unchanged — forging the displayed hexdocs URL or a suggested command, hiding text, or writing to the clipboard. No authentication or privileged position is required; only publishing a package.
This issue affects usage_rules: from 0.1.18 before 1.2.8.
CVE-2026-82584 is a low-severity vulnerability in ash-project igniter versions 0.8.1 up to but not including 0.8.4. It involves improper neutralization of escape, meta, or control sequences in the package metadata displayed by the mix igniter.install confirmation panel. This flaw allows a malicious package publisher to embed ANSI terminal escape sequences in metadata fields, enabling them to forge the confirmation prompt by overwriting displayed information such as author names and download counts. This deception can mislead developers into approving malicious dependencies.
CVE-2026-82586 is a high-severity vulnerability in ash-project's ash_lua component that allows Lua scripts to bypass field exposure restrictions. The vulnerability arises because the read operation in AshLua.Runtime resolves field names without consulting the exposed-field allow-list, enabling scripts to read any attribute, including private sensitive fields like hashed passwords. This affects versions from 0.1.0 up to but not including 0.2.1.
CVE-2026-81638 is a low-severity vulnerability in ash-project's ash_double_entry component. It involves improper handling of alternate encoding for ULID identifiers, allowing multiple distinct string representations to decode to the same underlying value. This can cause desynchronization or bypass of string-level checks such as idempotency, deduplication, deny-lists, audit correlation, or signature verification when IDs are exposed over HTTP or API boundaries. The issue affects versions from 0.1.0 up to but not including 1.0.19.
CVE-2026-82758 is an improper authentication vulnerability in ash-project's ash_authentication_oauth2_server. It allows unauthenticated attackers to register OAuth clients even when Dynamic Client Registration is supposed to be restricted by an initial access token. The issue arises because the secret resolution function treats empty or false values as valid secrets, enabling bypass of token checks. This affects versions from 0.1.0 up to but not including 0.3.1.
CVE-2026-82757 is a Server-Side Request Forgery (SSRF) vulnerability in ash-project's ash_authentication_oauth2_server affecting versions from 0.3.0 up to but not including 0.3.1. The vulnerability arises because the server incorrectly classifies certain IPv6 address ranges as publicly routable, allowing an attacker controlling a client metadata URL and its DNS to cause the server to connect to internal or loopback addresses. This could enable unauthorized internal network access via SSRF.
CVE-2026-82756 is an improper encoding or escaping of output vulnerability in ash-project's ash_authentication_oauth2_server. It allows an unauthenticated attacker to inject arbitrary authentication parameters into the WWW-Authenticate challenge header by manipulating tenant data used in the header construction. This affects versions from 0.1.3 up to but not including 0.3.1. The vulnerability can cause clients to follow attacker-controlled authorization server URLs within the authentication challenge. The CVSS 4.0 score is 6.3, indicating medium severity.
CVE-2026-82755 is a vulnerability in ash-project's ash_authentication_oauth2_server where sensitive OAuth discovery metadata intended for one tenant can be cached and served to another tenant due to improper cache control headers. This occurs because tenant-specific metadata endpoints are sent with Cache-Control: public and no Vary header, causing shared HTTP caches to serve cached responses across tenants. This can lead to clients sending authorization codes and secrets to incorrect token endpoints and validating tokens against wrong keys. The issue affects versions from 0.1.3 up to but not including 0.3.1.
CVE-2026-82754 is an improper protection of alternate path vulnerability in ash-project's ash_authentication_oauth2_server. The OAuth endpoints intended to be accessed under the /oauth prefix are also accessible under the /.well-known prefix due to route forwarding behavior. This allows bypassing security controls such as WAF rules, rate limits, or authentication exemptions that are scoped only to the canonical /oauth prefix. The vulnerability affects versions from 0.1.0 up to but not including 0.3.1.
CVE-2026-82753 is a resource exhaustion vulnerability in ash-project's ash_authentication_oauth2_server affecting versions from 0.3.0 up to but not including 0.3.1. An unauthenticated attacker can exploit the /authorize endpoint to create many client entries with large data fields, causing unbounded growth in database storage and memory usage. This occurs because the system lacks limits, expiry, or garbage collection for client rows created from client ID Metadata Documents, and caches documents before validation, including rejected ones.
CVE-2026-82752 is a medium severity vulnerability in the ash-project ash framework affecting versions from 0.10.0 up to but not including 3.33.0. It involves improper validation of specified quantity in input, where string length constraints are measured by Unicode graphemes rather than codepoints. This discrepancy allows an attacker to store arbitrarily large values in attributes despite small maximum length constraints, potentially leading to unbounded storage growth. The mismatch between validation and storage length counting can also cause data truncation or rejection at the database layer.
Incorrect Authorization vulnerability in ash-project ash returns records that a runtime read policy denies to any actor.
When a resource has an access_type :runtime read policy (a check evaluated per record rather than compiled to a filter), Ash.Policy.Authorizer decides each record in check_result/1 (lib/ash/policy/authorizer/authorizer.ex) by discarding impossible policy scenarios and inspecting what remains. When every scenario for a record was impossible, meaning no policy can authorize it and it must be forbidden, the empty-scenario branch instead kept the record ({[record | data], authorizer, any_forbidden?}) and returned it as authorized. As a result, records the runtime read policy denies are returned to any actor. The fix forbids a record whose scenarios are all impossible.
This issue affects ash: from 3.4.44 before 3.32.2.
Incorrect Authorization vulnerability in ash-project ash widens a relationship's parent(...) scoping filter to match unintended records when the referenced parent field cannot be resolved.
Loading a relationship whose filter references parent(...) resolves that expression against the parent record. resolve_parent_in_filter/3 (lib/ash/actions/read/relationships.ex) resolved an unresolvable parent reference (for example when the referenced field was not selected on the source query) to nil rather than failing. A scoping predicate such as org_id == parent(org_id) then becomes an IS NULL match, and a guard like is_nil(parent(org_id)) or org_id == parent(org_id) activates its unrestricted branch, so the relationship returns records the scope was meant to exclude. The fix fails the read with an error when a parent(...) reference cannot be resolved, instead of defaulting to nil.
This issue affects ash: from 3.13.2 before 3.32.2.