Orval Zod Codegen Flaw Allows Code Execution at Import Time via Unescaped Enum Defaults

What happened

A GitHub security advisory (GHSA-3575-w9fc-c2j6, tracked as CVE-2026-71868) reports that Orval, a popular OpenAPI-to-TypeScript client generator, emits enum-typed default values from an OpenAPI spec directly into a module-level JavaScript template literal when generating Zod validation schemas — without escaping backticks or ${...} sequences. Because template literal interpolation is evaluated at module load, a crafted default value such as v${<attacker JS>}w executes arbitrary code the moment the generated schema module is imported — no function call or runtime request is required. The reporter verified this on Orval 8.19.0 and notes it survives default OpenAPI validation. A public proof-of-concept (reproduce.sh / make_spec.py) is attached to the advisory, and the reporter flags that this is one of several default-bearing code paths reaching the same unescaped sink, meaning a single fix (proper escaping/encoding of default values) is expected to close them all.

Why it matters for defenders

This is a supply-chain-adjacent code generation vulnerability, not a runtime API flaw: exploitation happens during a build or codegen step, not against a deployed service. Any application, internal tool, or CI pipeline that runs Orval against an OpenAPI/Swagger specification it does not fully control — for example, a spec pulled from a third-party vendor, a partner integration, or any source where an attacker could influence enum default fields — is a candidate for import-time code execution on the machine (developer workstation, build agent, or CI runner) that generates and then imports the resulting Zod schema. Given how routinely OpenAPI specs are treated as low-trust, machine-generated artifacts, this creates a realistic path for an attacker to compromise build infrastructure or a developer's environment via a seemingly inert schema file.

What defenders should watch for or do now

• Inventory projects that use Orval to generate Zod schemas, and identify which of them consume OpenAPI specs from external, partner, or otherwise less-trusted sources.
• Treat generated schema output as untrusted until Orval ships and you adopt a fix that properly encodes default values (e.g., via JSON.stringify or correct escaping) rather than raw template-literal interpolation.
• In CI/build pipelines, consider reviewing or diffing generated code before it is committed or imported, particularly for changes touching enum defaults, and restrict which specs are allowed to drive codegen.
• As a hunting angle, look for anomalous process spawning, network calls, or file writes occurring during dependency install or codegen build steps rather than during application runtime — that timing is the signature of an import-time execution primitive like this one.
• Pin and audit the Orval version in use, and monitor for a patched release addressing this advisory before treating externally sourced OpenAPI specs as safe input to codegen.

Developing intel

This is a same-day advisory disclosure and details may evolve as the maintainers respond and a fix lands; there is no indication yet of in-the-wild exploitation. For the full technical writeup and proof-of-concept, see the original GitHub Security Advisory: GHSA-3575-w9fc-c2j6.