| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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 Validation of Specified Quantity in Input vulnerability in ash-project ash allows an attacker to store a value of arbitrary size in an attribute whose length constraint should bound it.
Ash measures string length with Elixir's String.length/1, which counts Unicode graphemes, in the max_length and min_length constraints of Ash.Type.String (apply_constraints/2 in lib/ash/type/string.ex), in Ash.Resource.Validation.StringLength, and in the string_length expression function. A grapheme carries an unbounded number of combining marks, so a base character followed by a million combining acute accents is one grapheme and megabytes of data, and satisfies max_length: 2. Where the data layer imposes no independent limit (ETS, Mnesia, or a Postgres text column) the whole value is persisted, so an attacker can write an entire request body into an attribute declared with a small maximum and grow storage without bound.
The counting unit also disagrees with the storage layer, which counts codepoints rather than graphemes, so a value accepted by the constraint can still be rejected or truncated by the column. A Postgres varchar(n) column bounds the value itself and is not exposed.
This issue affects ash: from 0.10.0 before 3.33.0. |
| Improper Authentication vulnerability in ash-project ash_authentication_oauth2_server allows an unauthenticated attacker to register OAuth clients even when Dynamic Client Registration is gated by an initial access token.
resolve_secret/3 in AshAuthentication.Oauth2Server (reached through __resolve_secret__!) treated any return other than {:ok, _} or :error from a configured {module, function, args} or 2-arity-function secret provider as a valid secret, wrapping nil, false, or "" as {:ok, value}. When the initial_access_token resolves to such an empty value, POST /oauth/register compares the presented bearer token against it and the comparison passes with no token supplied, so registration is open although it was configured closed. The same fail-open affected other resolved secrets such as signing_secret.
This issue affects ash_authentication_oauth2_server: from 0.1.0 before 0.3.1. |
| Server-Side Request Forgery (SSRF) vulnerability in ash-project ash_authentication_oauth2_server allows an attacker who controls a client metadata URL and its DNS to make the server connect to internal or loopback addresses.
public_ip?/1 in AshAuthentication.Oauth2Server.CIMD.ReqFetcher enforces the outbound policy for CIMD metadata fetches. It classified several address forms as publicly routable that are not: IPv4-compatible ::/96 (for example ::127.0.0.1), SIIT IPv4-translated ::ffff:0:0:0/96, and deprecated site-local fec0::/10. A returned AAAA record in one of these ranges passed the policy, so a fetch pinned to that address reached space the policy was meant to block.
This issue affects ash_authentication_oauth2_server: from 0.3.0 before 0.3.1. |
| Improper Encoding or Escaping of Output vulnerability in ash-project ash_authentication_oauth2_server allows an unauthenticated attacker to inject arbitrary authentication parameters into the WWW-Authenticate challenge header.
BearerPlug and RequireScopePlug built the Bearer resource_metadata="..." challenge by interpolating a resource_metadata URL derived from the request tenant directly into the quoted value. In a multi-tenant application that sets the Ash tenant from request-controlled data (a subdomain, the Host, a path segment, or a header), a tenant containing a " closes the quoted value and appends attacker-chosen auth-params, including a second resource_metadata URL pointing at an attacker-controlled authorization server that spec-following clients follow. Carriage returns and line feeds are rejected by Plug, so this is parameter injection within one header, not response splitting.
This issue affects ash_authentication_oauth2_server: from 0.1.3 before 0.3.1. |
| Use of Cache Containing Sensitive Information vulnerability in ash-project ash_authentication_oauth2_server allows a shared HTTP cache to serve one tenant's OAuth discovery metadata to another tenant's clients.
The RFC 8414 and RFC 9728 metadata endpoints in AshAuthentication.Phoenix.Oauth2Server.ProtocolRouter return tenant-specific values (issuer, authorization_endpoint, token_endpoint, jwks_uri) when a tenant is set, but sent them with Cache-Control: public, max-age=3600 and no Vary. When the tenant is derived from something other than the URL (a header or the Host) and a shared cache sits in front, the cache key is the URL alone, so a stored response for one tenant is served to another for up to an hour. Affected clients may then send authorization codes and secrets to the wrong tenant's token endpoint and validate tokens against the wrong keys.
This issue affects ash_authentication_oauth2_server: from 0.1.3 before 0.3.1. |
| Improper Protection of Alternate Path vulnerability in ash-project ash_authentication_oauth2_server exposes the state-changing OAuth endpoints under an unintended URL prefix, bypassing controls scoped to the canonical prefix.
oauth2_server_protocol_routes/1 in AshAuthentication.Phoenix.Oauth2Server.Router forwards the same ProtocolRouter at both the /oauth prefix and the /.well-known prefix. Phoenix forward strips the matched prefix before dispatch, so the full route table answers under both mounts, and POST /register, POST /token, and POST /revoke are reachable as /.well-known/register, /.well-known/token, and /.well-known/revoke. Edge controls such as WAF rules, rate limits, or authentication exemptions written against the /oauth paths, or that allow-list /.well-known as unauthenticated, do not apply to the alias.
This issue affects ash_authentication_oauth2_server: from 0.1.0 before 0.3.1. |
| Allocation of Resources Without Limits or Throttling vulnerability in ash-project ash_authentication_oauth2_server allows an unauthenticated attacker to exhaust database storage and memory.
The /authorize endpoint is unauthenticated by design. With Client ID Metadata Documents enabled, resolve_client/3 in AshAuthentication.Oauth2Server.CIMD fetches the document for each new URL-shaped client_id and upserts a client row, with no cap on the number of rows, no expiry or garbage collection, and no length bound on the fetched fields; the document was also placed in CIMD.Cache before validation, so even rejected documents held cache memory until their TTL. An attacker serving valid documents at many distinct URLs creates one permanent client row per URL, each able to carry multi-megabyte strings, growing storage and memory without bound.
This issue affects ash_authentication_oauth2_server: from 0.3.0 before 0.3.1. |
| 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. |
| Improper Protection of Alternate Path vulnerability in ash-project ash_lua allows a user-supplied Lua script to read attributes that are not on the exposed-field allow-list.
AshLua exposes Ash resources to Lua scripts, gated by a manifest declaring which fields are exposed. The read action's operation aggregate path in AshLua.Runtime took the field name straight from the Lua call and resolved it with only String.to_existing_atom and Ash.Query.Aggregate.new!, neither of which consults the exposed-field allow-list the normal fields path enforces. A script can therefore read the value of any attribute of any record the actor may read, including private sensitive?: true columns, via resource.read({ operation = {"list", "hashed_password"} }); min and max give a value oracle. Anyone able to submit or influence a Lua script can reach this.
This issue affects ash_lua: from 0.1.0 before 0.2.1. |
| Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in ash-project igniter allows a malicious package publisher to forge the mix igniter.install confirmation prompt.
mix igniter.install prints a confirmation panel (an anti-typosquatting safeguard) listing a package's hex metadata before adding it. The panel builder in Igniter.Project.Deps wrote publisher-controlled fields (meta.description, owner usernames, requirement names, version) to the terminal with only newlines stripped. A malicious or typosquatted package can embed ANSI terminal escape sequences (cursor movement, line erase, carriage returns) in its metadata to overwrite the panel, forging trusted author names and download counts while concealing the real ones, so a developer relying on the panel to vet the package is deceived into approving a malicious dependency.
This issue affects igniter: from 0.8.1 before 0.8.4. |
| Improper Handling of Alternate Encoding vulnerability in ash-project ash_double_entry allows an attacker to submit several distinct string spellings of the same identifier.
AshDoubleEntry.ULID renders a 128-bit ULID as 26 Crockford base-32 characters, but the first character encodes only 3 bits, so canonical values are 0 to 7. decode/1 in lib/ulid.ex masks the first character to its low 3 bits and valid?/1 accepts all 32 characters in that position, so 0..., 8..., G... and R... decode to the identical 16-byte value and resolve to the same row. When the type is exposed as a public ID over an HTTP or API boundary, an attacker-supplied ID can be spelled differently from the record it actually reads or writes, desynchronizing or bypassing string-level checks such as idempotency and deduplication keys, deny-lists, audit correlation, or signatures computed over the submitted ID.
This issue affects ash_double_entry: from 0.1.0 before 1.0.19. |
| Authorization Bypass Through User-Controlled Key vulnerability in ash-project ash_phoenix lets an attacker who controls filter form parameters filter across relationships the resource author marked non-public, turning the returned rows into a boolean oracle over private related data.
AshPhoenix.FilterForm resolved every relationship hop in the user-supplied path with Ash.Resource.Info.related/2, which traverses private relationships, and only checked the terminal field for publicity. parse_path_and_field/2 also rewrote a field naming a relationship into an extra path segment, so field=some_private_rel was accepted too. Both path and field come straight from form params, and the resulting ref went to Ash.Query.do_filter/2 without the public-only enforcement of Ash.Filter.parse_input/2. The fix resolves each hop with Ash.Resource.Info.public_relationship/2, rejecting the first non-public hop, and requires the terminal field to be public.
This issue affects ash_phoenix: from 0.6.0-rc.1 before 2.3.25. |
| Improper Validation of Specified Type of Input vulnerability in ash-project ash lets an attacker confuse the stored type tag of an Ash.Type.Union value that uses storage: :map_with_tag, bypassing that member's validation and any tag-based authorization.
For a union with storage: :map_with_tag, each member is identified in storage by a configured tag and tag_value. Ash.Type.Union.dump_to_native/2 (lib/ash/type/union.ex) did not force the configured tag when writing the value, so a tag carried in the submitted value was persisted verbatim. An attacker can therefore store a value whose data belongs to one member but whose tag names a different member. On read the value is re-selected by its tag and treated as the incompatible member (a type confusion), bypassing the real member's constraints and any logic or policy that branches on the union tag. The fix drops any incoming tag and forces the configured tag value on dump.
This issue affects ash: from 2.14.18 before 3.32.2. |
| Not Failing Securely (Failing Open) vulnerability in ash-project ash skips an Ash.Reactor change when the guard controlling it raises, so a change meant to run does not.
An Ash.Reactor change step can be gated by where validations that decide whether the change runs. Ash.Reactor.ChangeStep (lib/ash/reactor/steps/change_step.ex) evaluated those guards in apply_where_clauses/3, and apply_validation rescued any exception into {:error, error}. The reduce treated that identically to a guard whose condition was simply not met and bypassed the change. So when a guard raises (for example on attacker-influenced input), a change that enforces a security-relevant modification is skipped rather than failing the step. The fix distinguishes a raised exception (now {:raised, error}) and halts the step with an error, failing closed.
This issue affects ash: from 3.0.0-rc.17 before 3.32.2. |
| Improper Access Control vulnerability in ash-project ash lets a create action overwrite an existing record when the ETS or Mnesia data layer is used, because neither enforced primary-key uniqueness on insert.
Unlike a SQL data layer, whose unique primary-key constraint rejects a duplicate, the ETS and Mnesia data layers implemented create as a keyed insert that replaces any existing entry with the same primary key (lib/ash/data_layer/ets/ets.ex, lib/ash/data_layer/mnesia/mnesia.ex). An actor who can set the primary key on a create (for example a user-supplied string or integer key) can submit a create whose key matches an existing record and silently overwrite it, destroying and replacing another entity's data without going through the update action or its policies. The fix rejects a create whose primary key already exists with an already-taken error, and only allows duplicates for keyless resources.
This issue affects ash: from 0.4.0 before 3.32.2. |
| Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal application data from an HTTP 500 response body.
When a typed-controller route handler returns anything other than a %Plug.Conn{}, dispatch/3 in lib/ash_typescript/typed_controller/request_handler.ex passes the value to unexpected_return/2, which interpolates inspect(value, limit: 50) directly into the response message. The limit option bounds elements per collection rather than the term as a whole, so a handler falling through with a term such as {:error, %User{}} or a changeset serialises its full field set, including hashed passwords, tokens, and tenant identifiers, into the JSON error returned to the caller.
This contradicts the module's own posture elsewhere: the rescue clause gates Exception.message/1 behind AshTypescript.typed_controller_show_raised_errors?/0 and otherwise returns a generic message, while this path is ungated and always echoes.
This issue affects ash_typescript: from 0.15.0 before 0.18.0. |
| Improper Input Validation vulnerability in ash-project ash_typescript allows a remote attacker to submit argument values outside a declared allowlist or bound on typed-controller routes.
AshTypescript.TypedController.RequestHandler in lib/ash_typescript/typed_controller/request_handler.ex calls Ash.Type.cast_input/3 and treats an {:ok, cast} result as fully validated. In Ash these are separate steps: cast_input/3 only coerces the term, while every constraint declared on the argument is applied by Ash.Type.apply_constraints/3, which this path never calls. Constraints such as one_of, max_length, min and max, and match are therefore inert, so a value outside a declared allowlist is accepted and passed to the route handler. Codegen renders the same constraints into the generated TypeScript types, so an allowlist appears enforced to a TypeScript caller while any other HTTP client ignores it. Empty-string to nil normalization also lives in apply_constraints, so the allow_nil?: false check accepts "" for a required argument.
Where a constraint gates a role, a status, or a sort direction, this becomes a privilege or state-machine bypass.
This issue affects ash_typescript: from 0.15.0 before 0.18.0. |
| URL Redirection to Untrusted Site ('Open Redirect') vulnerability in ash-project ash_typescript allows an attacker who controls a path-parameter value to redirect a generated client's request, and the credentials attached to it, to an unintended route or an external origin.
The URL builders in lib/ash_typescript/typed_controller/codegen/route_renderer.ex replace each :param placeholder with a bare template interpolation and never call encodeURIComponent, so the value reaches executeTypedControllerRequest raw. A value containing ../ is normalised away by the fetch URL resolver and reaches a different route, while ? or # truncates the path and can smuggle or override query parameters. For a route whose path begins with a parameter, a value such as /evil.example.com/x yields the protocol-relative URL //evil.example.com/x, sending the request and the credentials from TypedControllerConfig to an attacker-controlled host. Nothing constrains the value at runtime: get_path_param_type/2 emits only a TypeScript type, which is erased.
The query-string path is unaffected, since URLSearchParams.set encodes its own values.
This issue affects ash_typescript: from 0.15.0 before 0.18.0. |
