Mocking the Mocker: RCE in Orval via OpenAPI Injection

In the modern web development stack, we love automation. We love tools that take a boring configuration file and spit out thousands of lines of boilerplate code so we don't have to. Orval is one of the heavy hitters in this space, specifically for the React/Vue/Svelte ecosystem. You feed it an OpenAPI specification (Swagger), and it generates type-safe query hooks and, crucially for this story, mock service worker (MSW) handlers.

The premise is simple: If your backend team defines the API structure, your frontend team shouldn't have to manually write mocks for testing. Orval reads the schema and generates TypeScript files containing fake data that matches the types.

But here is the catch: Code generators are effectively compilers. They take input (source) and produce executable output (target). If the compiler is naive about the input, it creates a bridge for an attacker to write directly into your codebase. In CVE-2026-24132, that bridge was the seemingly innocent const keyword in the OpenAPI spec.

The vulnerability lived in packages/mock/src/faker/getters/scalar.ts, inside a function named getMockScalar. This function is responsible for generating a mock value for simple types (strings, numbers, booleans) when the OpenAPI schema defines a specific constant value.

For example, if your schema says a field status must always be "success", Orval wants to generate TypeScript code that sets that property to "success". Ideally, you would do this by serializing the value safely. Orval, however, opted for the "trust me, I'm an engineer" approach of manual string concatenation.

When handling string types, the code effectively did this:

value = `'${item.const}'`;

It literally wrapped the input in single quotes and called it a day. For numbers and booleans, it just concatenated them directly. This is the code generation equivalent of SQL injection. The developer assumed item.const would be a benign string like "hello" or "user". They didn't anticipate that item.const might be a snippet of JavaScript designed to break out of that single-quote prison.

Let's look at the smoking gun. This diff shows exactly how the vulnerability was patched. The original code was trying to manually format the output string, which is almost always a security suicide mission when dealing with user-supplied input.

Vulnerable Code (The "Before"):

// packages/mock/src/faker/getters/scalar.ts
 
if (item.const) {
  if (isString) {
    // 🚨 DANGER: Direct interpolation
    return `'${item.const}'`;
  }
  // 🚨 DANGER: Direct concatenation for other types
  return '' + item.const;
}

Fixed Code (The "After"):

// packages/mock/src/faker/getters/scalar.ts
 
if (item.const) {
  // ✅ SAFE: Let JSON.stringify handle escaping
  return JSON.stringify(item.const);
}

The fix is elegantly simple: JSON.stringify(). This standard function handles quoting, escaping special characters (like newlines or existing quotes), and ensures the output is a valid JavaScript literal. If you pass it a string containing a quote, it escapes it (\"). If you pass it a number, it stays a number. The vulnerability existed solely because the generator tried to reinvent the wheel of serialization.

So, how do we turn a bad string concatenation into Remote Code Execution? We need to provide an OpenAPI specification where a const value breaks the JavaScript syntax of the generated file.

Imagine an attacker convinces a developer to use a malicious openapi.yaml. Maybe it's a pull request to a shared repo, or a compromised remote spec URL.

The Malicious Spec:

openapi: 3.0.0
info:
  title: Pwned API
  version: 1.0.0
paths: {}
components:
  schemas:
    TrojanHorse:
      type: object
      properties:
        status:
          type: string
          # The Injection Payload:
          const: "'); require('child_process').execSync('calc'); //"

The Generated Code:

When Orval runs, it takes that const string and wraps it in quotes. The resulting TypeScript file looks like this:

export const getTrojanHorseMock = () => ({
  // The generated line:
  status: ''); require('child_process').execSync('calc'); //'
});

Let's break that down:

1. status: ' starts the string assignment.
2. '); closes the string and the object definition immediately.
3. require('child_process').execSync('calc'); executes the attacker's command (popping a calculator, or stealing SSH keys).
4. //' comments out the trailing quote that Orval added, preventing a syntax error.

The next time the developer runs their tests or starts their mock server, the code executes. Game over.

This isn't a vulnerability in the production application; it's a vulnerability in the development lifecycle. This is arguably more dangerous because developer machines often have elevated privileges: SSH keys to production, AWS credentials in ~/.aws/credentials, and write access to the source code repo.

Furthermore, this attack works beautifully in CI/CD pipelines. If your pipeline creates a build environment, pulls the latest specs, generates the client/mocks, and runs tests, the attacker has achieved code execution inside your build agent. They can dump environment variables (secrets) and send them to a remote server before the build even fails.

Because this happens at generation time (or rather, execution-of-generated-code time), standard application firewalls (WAFs) protecting your production API won't save you here. The attack payload enters via a YAML file, not an HTTP request to your app.

The remediation is straightforward: Update Orval. If you are on the v7 branch, move to 7.20.0. If you are living on the edge with v8, update to 8.0.3.

If you cannot update immediately, you must strictly validate the OpenAPI specifications you consume. Do not pull specs from untrusted URLs or allow external contributors to modify the spec file without manual review of the const fields.

For tool authors reading this: Never build code by concatenating strings. Always use an Abstract Syntax Tree (AST) builder (like ts-morph or babel/types) or, at the very least, standard serialization functions like JSON.stringify to generate literals. Code generation is hard; secure code generation is harder.