CVE-2026-96758 in orval
Summary
by MITRE • 09/23/2026
orval @orval/core before 8.28.0 contains a code injection vulnerability in the form-data serializer that fails to escape multipart property names in generated template literals. Attackers can inject ${...} expressions into OpenAPI schema property names that execute as live interpolation when the generated client builds FormData bodies with consumer process privileges.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in orval versions prior to 8.28.0 represents a critical code injection flaw within its form-data serialization logic, specifically targeting the handling of multipart property names during API request construction. Orval is widely utilized as an OpenAPI client generator that produces TypeScript and JavaScript SDKs for interacting with RESTful APIs. The core issue arises from how the library processes schema-defined property names when constructing FormData objects. In standard web development practices, form data often requires specific encoding to ensure special characters are transmitted correctly without corrupting the payload structure or introducing security risks. However, in this implementation, the serializer fails to properly escape or sanitize multipart property names before embedding them into generated template literals. This oversight creates a direct pathway for malicious input to be interpreted as executable code rather than static data strings.
From a technical perspective, the flaw is rooted in the use of JavaScript template literals without adequate sanitization of dynamic inputs derived from OpenAPI schema definitions. When an attacker controls or influences the property names defined within an OpenAPI specification that Orval consumes, they can inject string fragments containing ${...} syntax. In JavaScript environments, this syntax triggers live interpolation, meaning any code enclosed within these delimiters is evaluated and executed at runtime by the consumer application. This behavior transforms what should be a simple key-value pair in a multipart form submission into an arbitrary code execution vector. The vulnerability effectively bypasses standard input validation mechanisms because the injection occurs during the generation of client-side code or its immediate execution context, depending on how the generated SDK is integrated and invoked within the host application.
The operational impact of this vulnerability is severe due to the privilege level at which the injected code executes. Since the form-data building process typically runs with the same privileges as the consuming user's browser session or Node.js environment, successful exploitation allows an attacker to execute arbitrary JavaScript in that context. This can lead to a range of malicious outcomes including cross-site scripting attacks if running in a browser, data exfiltration by accessing sensitive local storage or cookies, session hijacking through manipulation of authentication tokens, and potentially remote code execution if the generated client is used within a Node.js backend environment where such vulnerabilities often translate directly into server compromise. The risk is amplified because OpenAPI schemas are frequently sourced from third-party providers or internal services that may not have rigorous input validation on their metadata definitions, making them susceptible to manipulation by adversaries who can influence API documentation sources.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) as it involves the generation and execution of code based on untrusted input without proper neutralization techniques. Furthermore, in the context of the MITRE ATT&CK framework, this behavior maps to T1059 Command and Scripting Interpreter, specifically JavaScript interpretation capabilities within a web or application environment. The attack vector leverages the trust placed in generated client libraries to execute unintended commands, exploiting the dynamic nature of template literals which are designed for convenience but can become dangerous when combined with unsanitized external data sources.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. Users running affected versions should upgrade immediately to orval version 8.28.0 or later, where the form-data serializer has been patched to properly escape multipart property names before inclusion in template literals. For organizations unable to update instantly, implementing a strict Content Security Policy can help mitigate some downstream effects by restricting script execution sources and preventing certain types of data exfiltration. Additionally, developers should audit their OpenAPI schema inputs for any external control over property naming conventions and consider adding custom sanitization layers within the API gateway or documentation generation pipeline to ensure that only safe alphanumeric characters are permitted in field names used for form submissions. Regular security reviews of generated code artifacts can also help identify similar patterns where dynamic string interpolation is used with unverified data sources, preventing recurrence of such injection flaws in future software updates.