CVE-2026-105283: Internal error terms inspected into AshTypescript RPC error responses
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ashtypescript 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.builderrorresponse/1 in lib/ashtypescript/rpc/errorbuilder.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 castmaptostruct/2 in lib/ashtypescript/rpc/inputformatter.ex throws the raw Ash.Type cast error into the builder, and field selection on a generic action that returns a primitive, where formatfieldtype/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 ashtypescript: from 0.1.0 before 0.19.1.
Affected Software
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
An attacker does not need authentication or user interaction. They must be able to send RPC requests that trigger an unhandled error-builder fallback, such as an invalid nested value for a struct-typed action argument or field selection on a generic action returning a primitive.
Which deployments are exposed?
Deployments exposing AshTypescript RPC over HTTP or channels are exposed when those request paths are reachable by an unauthenticated attacker. The affected fallback places inspected internal terms directly in client-facing response fields.
What information can be disclosed?
The response can include the inspected raw pipeline error term in details.error, or a full Ash.Info.Manifest.Type struct in vars.returnType. The exact data disclosed depends on what the unhandled term carries; resource module names in vars.resource are explicitly not considered sensitive in the advisory description.
How can I check whether an instance is affected?
Review RPC error responses generated by invalid nested values supplied to struct-typed action arguments and by field selection on generic actions returning primitives. An affected instance returns internal inspected terms rather than redacting the error behind an errorId.