Internal error terms inspected into AshTypescript RPC error responses

Summary

Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to read internal Elixir terms from an RPC error response by provoking an error the error builder has no dedicated clause for.

AshTypescript.Rpc.ErrorBuilder.build_error_response/1 in lib/ash_typescript/rpc/error_builder.ex renders a pipeline error term that matches no specific clause with inspect/1 and places the result in details.error of the client-facing error. Ash exceptions take a separate path in AshTypescript.Rpc.Errors where unhandled cases are redacted behind an errorId, but these fallbacks have no redaction, so whatever the term carries reaches the HTTP or channel response. Two request paths hand it such terms: a struct-typed action argument with an invalid nested value, where cast_map_to_struct/2 in lib/ash_typescript/rpc/input_formatter.ex throws the raw Ash.Type cast error into the builder, and field selection on a generic action that returns a primitive, where format_field_type/1 inspects the full Ash.Info.Manifest.Type struct into vars.returnType. Resource module names in vars.resource are not treated as sensitive and are out of scope.

This issue affects ash_typescript: from 0.1.0 before 0.19.1.

Details

1. Error funnel. AshTypescript.Rpc.run_action/3 runs the request through Pipeline.parse_request/3, execute_ash_action/1 and process_result/2. Any {:error, reason} from these goes to error_response/1, which calls AshTypescript.Rpc.ErrorBuilder.build_error_response/1 with the raw reason term.

2. Unredacted fallbacks. build_error_response/1 has clauses for the error tuples the pipeline is expected to emit. A two-tuple whose first element is an atom but matches no clause is rendered as field_validation_error with details.error set to inspect(error), and any other term becomes unknown_error with details.error set to inspect(other). Ash exceptions never reach these clauses because AshTypescript.Rpc.Errors handles them and redacts unhandled ones behind an errorId, so only this path has no redaction.

3. Reachable triggers. AshTypescript.Rpc.InputFormatter.cast_map_to_struct/2 throws the raw Ash.Type.cast_input/3 error, a keyword list, when a struct-typed argument fails to cast, and format/6 turns the throw into {:error, term} for the funnel. Separately, requesting fields on a generic action whose return type is a primitive produces an {:invalid_field_selection, :primitive_type, return_type, ...} tuple whose return_type is formatted by format_field_type/1, which inspects the whole Ash.Info.Manifest.Type struct, constraints and decoration included, into vars.returnType.

Proof of concept

1. Expose an AshTypescript RPC action that takes a struct-typed argument, for example an assignee argument whose struct has a UUID id field.
2. Send the action request with an invalid nested value, such as {"assignee": {"id": "not-a-uuid", "name": "x", "email": "e"}}.
3. Read the response: each pair of the raw Ash.Type cast error is returned as its own field_validation_error with the inspected term in details.error.

For the second path, send a fields list to a generic action that returns a primitive and read the inspected Ash.Info.Manifest.Type struct in vars.returnType of the resulting error.

Impact

Any client able to call the RPC endpoint can submit malformed struct arguments or field selections and read internal Elixir terms, including any state the failing pipeline step carried, from the error response.

Configurations

The application exposes an AshTypescript RPC endpoint over HTTP or a channel and has an action with a struct-typed argument, or a generic action with a primitive return type that accepts field selection.