CVE-2026-82733 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 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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the ash_typescript library represents a critical information disclosure flaw stemming from improper error handling mechanisms within its typed controller request handler architecture. This security defect allows unauthenticated attackers to extract sensitive internal application data by triggering specific HTTP errors that result in verbose server responses. The core of the issue lies in the dispatch logic located in lib/ash_typescript/typed_controller/request_handler.ex, where the system fails to sanitize or mask error messages before transmitting them back over the network interface. When a route handler returns a value that is not an instance of %Plug.Conn{}, which indicates a deviation from expected control flow such as returning an error tuple directly rather than a proper connection struct, the framework invokes the unexpected_return/2 function. This function proceeds to serialize the returned term into JSON format for inclusion in the HTTP response body without applying necessary security filters or masking protocols.
The technical mechanism of this vulnerability relies on how the Elixir inspect function is utilized during serialization. The code applies a limit parameter set to fifty elements, which restricts the depth of collection traversal but does not constrain the total size or sensitivity of individual fields within those collections. Consequently, if a handler returns a complex data structure such as an error tuple containing a User struct or a changeset object, the serializer will traverse and include all accessible attributes of that object. This includes highly sensitive information such as hashed passwords, authentication tokens, tenant identifiers, and other private metadata. Because this serialization occurs within the HTTP 500 Internal Server Error response body, any client capable of inducing an error condition can receive these details in plaintext JSON format. The vulnerability is particularly dangerous because it bypasses standard security postures where exception messages are typically gated behind configuration flags that restrict detailed output to administrators only.
From a threat modeling perspective, this flaw aligns with CWE-209: Generation of Error Message Containing Sensitive Information and CWE-532: Information Exposure Through Log Files if the error is also logged internally before being sent to the client. The attack vector falls under MITRE ATT&CK technique T1486: Data Encrypted for Impact, although in this case it is more accurately categorized as data exfiltration through improper output handling rather than encryption abuse. Specifically, it relates to information leakage via error messages which can be exploited during reconnaissance phases of an attack chain. An attacker does not need valid credentials or prior authentication; they merely need to identify endpoints that might fail under specific input conditions and trigger those failures to harvest the resulting verbose responses. The presence of hashed passwords in these leaks is particularly severe, as it provides attackers with material for offline brute-force attacks against user accounts, potentially leading to full account compromise if weak hashing algorithms or common passwords are used.
The operational impact extends beyond immediate data theft. Exposure of tenant identifiers can facilitate multi-tenancy isolation failures, allowing an attacker from one tenant context to infer the existence and structure of other tenants within the same deployment. This aids in lateral movement and targeted attacks against higher-value targets within the system. Furthermore, exposure of authentication tokens could allow session hijacking if those tokens are used for subsequent API calls or web requests without proper expiration checks on the client side. The inconsistency in error handling is also a significant architectural weakness; while other parts of the module correctly gate exception messages behind a configuration flag typed_controller_show_raised_errors?, this specific code path remains ungated and always echoes detailed information regardless of deployment environment settings. This lack of consistency suggests that security controls are not uniformly applied across all execution paths, increasing the attack surface significantly.
Mitigation strategies must focus on enforcing strict output sanitization for all error responses generated by the framework. Developers should ensure that any data returned in HTTP 500 responses is stripped of sensitive fields such as passwords, tokens, and internal identifiers before serialization. Implementing a centralized exception handler that applies consistent masking rules across all code paths would resolve the inconsistency between gated and ungated error handling mechanisms. Additionally, enabling detailed error reporting only in development environments via configuration flags can prevent production exposure. For users affected by this vulnerability, upgrading to ash_typescript version 0.18.0 or later is required as it addresses these flaws through improved serialization logic that respects security boundaries regardless of the return type from route handlers. Until an upgrade is performed, implementing a reverse proxy rule to strip detailed error bodies from HTTP responses can provide temporary relief against exploitation.