CVE-2026-71867: Orval: RCE via schema property name -> computed-property-key injection in the MSW mock generator
Summary
orval, when generating MSW mocks (output.mock: true), emits each schema property name as a single-quoted object key in the mock factory WITHOUT escaping the single quote. A ' in a property name closes the key and lands in object-literal context, where an injected computed property key [expr] is evaluated when the mock factory is called (e.g. in tests / MSW handlers) -> RCE. The property name is a pure data field. Verified on orval 8.19.0 / Node.
Details
ts export const getOpResponseMock = (...): Thing => ({'x': 0, [require("fs").writeFileSync("PWNED","")]: 0, 'y': faker...., ...overrideResponse});
Safe elsewhere: the zod schema double-quotes the property name; the TS interface key is a type (DoS only). Distinct from orval's $ref / route-path / server-url / zod-default findings.
PoC
reproduce.sh (+ makespec.py) attached: a property name x': 0, [require("fs").writeFileSync("<marker>","")]: 0, 'y -> mock object literal; calling the mock factory writes the marker. Verified on 8.19.0.
Impact
JavaScript / OS command execution (via childprocess) on the machine of anyone who generates orval mocks from an attacker controlled spec and runs them (tests / MSW).
Suggested fix
Escape the property name for the JS string key (JSON.stringify), and never interpolate a raw property name adjacent to [ ] in object-literal position.
Other sources
Orval generates type-safe JavaScript clients in TypeScript from OpenAPI v3 and Swagger v2 specifications. Prior to 8.21.0, a single quote in a schema property name is emitted into single-quoted object keys in generated MSW mock factories without safe encoding. This permits attacker-controlled JavaScript to be evaluated when the generated mock factory is called by tests or an MSW handler, resulting in code execution in the developer, CI, test, or application environment. The affected code is packages/core/src/getters/keys.ts function getKey and MSW mock generation. This issue is fixed in version 8.21.0.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/orvalto a version that resolves this vulnerability.Fixed in 8.21.0 - Upgrade
Upgrade
orvalto a version that resolves this vulnerability.Fixed in 8.21.0 - Configuration
In orval’s MSW mock generation code path, escape schema property names for JS string keys (e.g., via JSON.stringify) and never emit a raw property name adjacent to [ ] in object-literal computed-property-key context (the unsafe single-quoted key emission prior to 8.21.0 enables computed-property-key injection).
JavaScript MSW mock generator (orval packages/core/src/getters/keys.ts function getKey) Escape schema property names when emitting JavaScript object-literal keys = Use JSON.stringify (escape property name for JS string key) before emitting as object key; avoid interpolating raw property names adjacent to computed-property key syntax ([...])
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users of Orval versions before 8.21.0 are exposed if they generate MSW mocks from an OpenAPI or Swagger specification containing attacker-controlled schema property names. The generated code executes when the affected mock factory is called by tests or an MSW handler, potentially affecting developer workstations, CI, test, or application environments.
What does an attacker need to exploit it?
An attacker needs influence over a schema property name in the OpenAPI v3 or Swagger v2 input used to generate MSW mocks. A single quote in that property name can inject JavaScript into a generated single-quoted object key.
How can I determine whether generated output is affected?
Review generated MSW mock factories for schema-derived object keys containing unescaped single quotes or unexpected JavaScript. The affected generation path includes packages/core/src/getters/keys.ts, specifically getKey, and MSW mock generation.
What is the remediation?
Upgrade Orval to version 8.21.0, which fixes the issue. Regenerate affected MSW mock output after upgrading so previously generated vulnerable code is replaced.