CVE-2026-82732 in ash_typescript
Summary
by MITRE • 09/01/2026
Improper Input Validation vulnerability in ash-project ash_typescript allows a remote attacker to submit argument values outside a declared allowlist or bound on typed-controller routes.
AshTypescript.TypedController.RequestHandler in lib/ash_typescript/typed_controller/request_handler.ex calls Ash.Type.cast_input/3 and treats an {:ok, cast} result as fully validated. In Ash these are separate steps: cast_input/3 only coerces the term, while every constraint declared on the argument is applied by Ash.Type.apply_constraints/3, which this path never calls. Constraints such as one_of, max_length, min and max, and match are therefore inert, so a value outside a declared allowlist is accepted and passed to the route handler. Codegen renders the same constraints into the generated TypeScript types, so an allowlist appears enforced to a TypeScript caller while any other HTTP client ignores it. Empty-string to nil normalization also lives in apply_constraints, so the allow_nil?: false check accepts "" for a required argument.
Where a constraint gates a role, a status, or a sort direction, this becomes a privilege or state-machine bypass.
This issue affects ash_typescript: from 0.15.0 before 0.18.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the ash-typescript library represents a critical failure in input validation logic within the TypedController.RequestHandler component, specifically located in lib/ash_typescript/typed_controller/request_handler.ex. This flaw allows remote attackers to bypass declared constraints on typed-controller routes by submitting argument values that fall outside of specified allowlists or bounds. The root cause lies in how the application processes incoming data for type casting and validation. When a request is received, the system invokes Ash.Type.cast_input/3, which is designed solely to coerce terms into their expected types rather than to enforce business logic constraints. The code incorrectly assumes that receiving an {:ok, cast} tuple from this function signifies complete validation success. However, in the underlying Ash framework architecture, type coercion and constraint application are distinct operations. While cast_input handles data transformation, it does not evaluate rules such as allowed values, length limits, or pattern matches.
The specific technical deficiency is that the code path fails to invoke Ash.Type.apply_constraints/3 after successful casting. This function is responsible for enforcing constraints like one_of, max_length, min, and max declarations defined on arguments. Because this step is skipped, these security controls remain inert during request processing. Consequently, a value outside a declared allowlist is accepted as valid and passed directly to the route handler logic. This discrepancy creates a significant trust boundary issue where the server-side enforcement of data integrity is effectively disabled for HTTP clients that do not utilize the generated TypeScript types. The code generation process renders these constraints into client-side TypeScript definitions, creating an illusion of security for developers using the official SDKs who rely on static type checking. However, any other HTTP client or malicious actor can bypass this perceived protection by sending raw requests with invalid data structures directly to the API endpoints.
The operational impact of this vulnerability is severe, particularly in scenarios where input constraints govern access control decisions or state machine transitions. For instance, if a constraint restricts valid values for a role parameter, status field, or sort direction, an attacker can submit unauthorized values that were explicitly excluded by the developer's intent. This leads to privilege escalation or state-machine bypass vulnerabilities, allowing users to perform actions they are not authorized to execute or manipulate application states in unintended ways. Additionally, the vulnerability affects empty-string normalization logic which resides within apply_constraints/3. Due to the missing constraint check, an allow_nil?: false requirement on a required argument can be circumvented by submitting an empty string instead of nil, effectively bypassing mandatory field validation and potentially leading to downstream errors or unexpected behavior in business logic that assumes non-empty input.
This issue affects versions of ash_typescript from 0.15.0 up to but not including version 0.18.0. To mitigate this vulnerability, developers must ensure that the full constraint application pipeline is executed for all incoming requests regardless of their source or type. This involves explicitly calling Ash.Type.apply_constraints/3 after cast_input/3 returns a success tuple and verifying that no constraints are violated before proceeding with route handling. Implementing comprehensive server-side validation checks independent of client-side types is essential to prevent bypasses via raw HTTP clients. Security teams should audit existing implementations for similar patterns where type coercion is mistaken for full input validation. From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-862 Missing Authorization, as it allows unauthorized access through insufficient checking of user-supplied data. In terms of the MITRE ATT&CK framework, this technique relates to T1190 Exploit Public-Facing Application, where attackers leverage flaws in web application input handling to achieve unintended outcomes such as privilege escalation or state manipulation.