Orval MSW Mock Generator: Unescaped Schema Property Names Enable RCE (GHSA-2w86-xfrc-g85r)

A newly published GitHub Security Advisory (GHSA-2w86-xfrc-g85r, tracked as CVE-2026-71867) reports a code-injection vulnerability in orval, a popular OpenAPI-to-TypeScript client/mock generator for the npm ecosystem.

What was reported

According to the advisory, when orval generates MSW mocks (output.mock: true), it emits each OpenAPI schema property name as a single-quoted JavaScript object key inside the generated mock factory function — without escaping embedded single quotes. A property name containing a ' can therefore close the string key early and inject a JavaScript computed property key ([expr]) into the object literal. That expression is evaluated whenever the generated mock factory is invoked, such as during test runs or MSW request handling. The reporter states this was verified against orval 8.19.0 on Node.js, with a proof-of-concept (reproduce.sh / make_spec.py) that uses a crafted property name to trigger require("fs").writeFileSync(...) as a demonstration of arbitrary code execution. The advisory notes this is distinct from other orval findings involving $ref, route paths, server URLs, or zod defaults, and that the zod-schema and TypeScript-interface code paths are not affected the same way (the TS interface issue is characterized only as a DoS risk).

Why it matters for defenders

The root cause described is that a schema property name — ordinary data from an OpenAPI spec — flows unescaped into a JavaScript object-literal context in generated code. Any team that generates orval MSW mocks from an OpenAPI/Swagger spec they do not fully trust (third-party APIs, partner-supplied specs, specs pulled from external services) is exposed: simply generating and then executing the mock factory (e.g., running the test suite or starting MSW handlers) can result in code execution on the developer or CI machine that runs it. Because generated mock code is often executed automatically as part of test pipelines, this could translate into a supply-chain-style compromise of developer workstations or CI runners rather than requiring any unusual user interaction beyond normal build/test workflows.

What defenders should watch for or do now

• Inventory usage of orval with output.mock: true across repos and CI pipelines, and identify whether any input specs originate from external or untrusted sources.
• Until a patched release is available and confirmed, treat OpenAPI specs from untrusted or third-party sources as executable input, not inert data — review specs for anomalous property names (e.g., containing quotes, brackets, or JS syntax) before generating mocks against them.
• In CI, review generated mock files (diff review) before they are executed, and consider running spec-to-code generation steps in an isolated/sandboxed environment separate from credentialed CI runners.
• Hunt for unexpected file-write or process-spawn activity (e.g., unexpected child_process or filesystem calls) originating from Node test runners or MSW-related processes in CI logs and EDR telemetry, particularly around test execution following a dependency or spec update.
• Track the advisory for a fixed orval version and upgrade once available; the suggested remediation per the report is proper JS-string escaping (e.g., via JSON.stringify) of property names used as object keys, and avoiding raw property-name interpolation adjacent to [ ] in object-literal position.

This is developing intel based on a single GitHub Security Advisory published 2026-09-03 with a public proof-of-concept; details may be updated as the maintainers and reporter respond. See the original advisory for full technical detail: GHSA-2w86-xfrc-g85r.