CVE-2026-77950 in ash_typescript
Summary
by MITRE • 09/01/2026
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_typescript allows an unauthenticated attacker to receive unredacted internal error data by provoking an error shape the configured error handler does not match.
apply_error_handler/3 in lib/ash_typescript/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 ash_typescript: from 0.8.0 before 0.18.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the ash_typescript library represents a critical flaw in error handling logic within the Ash framework ecosystem, specifically affecting versions ranging from 0.8.0 to just prior to 0.18.0. This issue stems from an improper generation of error messages that contain sensitive information, allowing unauthenticated attackers to retrieve unredacted internal error data. The core technical flaw resides in the apply_error_handler/3 function located within lib/ash_typescript/rpc/errors.ex, which serves as the primary hook for applications to redact or suppress errors before they are transmitted to the client side. Under normal operational conditions, this handler is expected to process incoming error structures and return a sanitized version or nil if suppression is desired. However, the implementation contains a critical logic gap where the rescue clause fails to properly handle cases where the configured error handler does not match the shape of the generated error.
When an application defines custom error handlers using conventional pattern-matching functions over expected error shapes, any deviation from these patterns results in a FunctionClauseError being raised by the Erlang runtime. The current implementation catches this exception within its rescue block but incorrectly logs only a warning message and subsequently returns the original, pre-handler error map to the client. This behavior effectively negates the security intent of the error handler mechanism. Instead of suppressing or redacting sensitive data as intended when an unexpected error shape occurs, the system inadvertently publishes the raw transformed error object. These objects often contain internal variables (vars) that may include secrets such as database credentials, API keys, user identifiers, or other confidential business logic details. Consequently, an intent to suppress an error is paradoxically converted into an action that explicitly publishes it to the attacker.
The operational impact of this vulnerability is significant for any application relying on ash_typescript for its TypeScript RPC layer without implementing additional defensive measures. An unauthenticated attacker can trigger specific conditions that result in unexpected error shapes, thereby forcing the system to leak internal state information. This exposure facilitates further reconnaissance and potentially aids in more sophisticated attacks such as privilege escalation or data exfiltration by revealing architectural details and sensitive configuration parameters. The flaw is particularly insidious because it exploits a common development pattern where developers assume their custom handlers will always match incoming error structures, leading to complacency in security design around error handling routines.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information and CWE-755: Improper Handling of Unexpected Exceptional Condition. It also relates to ATT&CK technique T1486: Data Encrypted for Impact in the context of information disclosure leading to system compromise, although primarily it falls under reconnaissance phases like T1078: Valid Accounts or general data leakage vectors depending on the specific sensitive data exposed. The root cause is a failure in input validation and exception handling logic within the framework itself rather than user code, making it a library-level security defect that requires an update to resolve.
To mitigate this vulnerability, organizations must upgrade ash_typescript to version 0.18.0 or later where the error handling logic has been corrected to properly handle unmatched error shapes without leaking internal data. For applications unable to immediately upgrade, developers should implement custom middleware or wrapper functions around the RPC layer that enforce strict output sanitization regardless of the framework's default behavior. This includes ensuring that all error responses are validated against a whitelist of allowed fields before being serialized and sent over the network. Additionally, logging mechanisms should be reviewed to ensure they do not inadvertently store sensitive data in plain text logs during these exception scenarios. Regular security audits focusing on error handling paths across the application stack are recommended to prevent similar issues from arising due to developer assumptions about framework behavior.