CVE-2026-77950: RPC error handler fails open in AshTypescript, disclosing unredacted errors
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ashtypescript allows an unauthenticated attacker to receive unredacted internal error data by provoking an error shape the configured error handler does not match.
applyerrorhandler/3 in lib/ashtypescript/rpc/errors.ex is the only hook an application has for redacting or suppressing errors before they reach the client, with a nil return dropping the error entirely. Its rescue clause logs a warning and then returns the original, pre-handler error map. Error handlers are conventionally written as pattern-matching functions over expected error shapes, so an unmatched shape raises FunctionClauseError and the raw transformed error, including any secrets carried in vars, is emitted instead. An intent to suppress an error becomes an intent to publish it. The rescue catches exceptions only, so a handler that throws or exits still propagates.
This issue affects ashtypescript: from 0.8.0 before 0.18.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash-project ash_typescriptto a version that resolves this vulnerability.Fixed in 0.18.0 - Configuration
In apply_error_handler/3, return nil to drop the error entirely when the error could contain sensitive information, instead of logging and returning the original pre-handler error map.
ash_typescript (apply_error_handler/3 in lib/ash_typescript/rpc/errors.ex) error_handler_return_behavior = nil - Compensating control
Ensure only authenticated/authorized clients can reach the RPC endpoints that may trigger the unmatched error-handler shape, since the vulnerability allows an unauthenticated attacker to provoke errors and receive unredacted internal error data.
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications using ash_typescript versions from 0.8.0 before 0.18.0 are affected when they rely on apply_error_handler/3 to redact or suppress RPC errors. The attacker does not need to authenticate.
What must an attacker do to obtain unredacted error data?
They must provoke an error whose shape does not match the configured error handler. A pattern-match failure raises FunctionClauseError, causing the rescue clause to return the original pre-handler error map to the client.
Does configuring an error handler to suppress errors prevent disclosure?
Not reliably in affected versions. Although a handler can return nil to drop an error, an unmatched error shape causes the handler to fail and the original error, potentially including secrets in vars, is emitted instead.
What is the immediate mitigation if upgrading is not possible?
Ensure configured error handlers handle unexpected error shapes rather than relying only on pattern-matching clauses. The provided data does not identify another built-in mitigation for the fail-open rescue behavior.