CVE-2026-71866 in Orval
Summary
by MITRE • 08/19/2026
Orval generates type-safe JavaScript clients in TypeScript from OpenAPI v3 and Swagger v2 specifications. From version 8.19.0 until 8.21.0, a double quote in a schema property name is emitted into the generated zod.object({...}) schema without safe encoding. This permits attacker-controlled JavaScript to be evaluated when the generated zod schema module is imported, resulting in code execution in the developer, CI, test, or application environment. The affected code is packages/zod/src/index.ts and zod object-key generation. This issue is fixed in version 8.21.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Orval versions 8.19.0 through 8.21.0 represents a critical server-side template injection flaw within the code generation process, specifically affecting the output of Zod schema definitions. Orval is widely utilized by development teams to automatically generate type-safe JavaScript and TypeScript clients from OpenAPI v3 and Swagger v2 specifications, streamlining API integration while ensuring type consistency across frontend and backend systems. The core issue arises during the transformation of raw specification data into executable code structures, where input validation and sanitization mechanisms are insufficiently robust against malicious payloads embedded within schema property names.
The technical root cause lies in the handling of string literals when generating Zod object schemas via the packages/zod/src/index.ts module. When a developer provides an OpenAPI or Swagger specification containing a property name that includes double quotation marks, Orval fails to properly escape these characters before embedding them into the generated JavaScript code. Instead of converting the quotes into safe escaped sequences such as backslash-quote pairs, the tool emits the raw unescaped double quotes directly into the source file. This oversight transforms what should be a static data definition into an executable context where user-controlled input is interpreted by the JavaScript engine without adequate safeguards.
The operational impact of this vulnerability is severe due to its potential for arbitrary code execution within the developer environment, continuous integration pipelines, and production application contexts. When the generated Zod schema module is imported or executed during the build process, the unescaped double quotes can break out of their intended string literal boundaries. This allows an attacker who controls the API specification to inject malicious JavaScript payloads that are evaluated by the Node.js runtime or browser environment where the code generation occurs. Consequently, this leads to Remote Code Execution (RCE), enabling potential data exfiltration, supply chain compromise through poisoned dependencies, or disruption of development workflows via denial-of-service conditions triggered by malformed execution contexts.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code, often referred to as code injection, and falls under the ATT&CK technique T1059 Command and Scripting Interpreter for initial access or lateral movement if exploited in automated pipelines. The lack of input validation on schema property names violates fundamental principles of secure coding regarding the separation of data and executable logic. Developers relying on Orval assume that generated code is safe to execute, making this trust boundary violation particularly dangerous as it bypasses traditional security controls by operating within legitimate build tools.
Mitigation strategies require immediate action for organizations using affected versions. The primary remediation is to upgrade Orval to version 8.21.0 or later, where the issue has been resolved through proper escaping of special characters in generated schema keys. For environments that cannot immediately update, developers should audit their OpenAPI specifications to ensure no property names contain double quotes or other control characters that could break string literals. Additionally implementing strict linting rules on API definitions and validating input data before it reaches code generation tools can provide a defensive layer against similar injection vectors in future versions or related tooling.