Orval Zod Generator: Import-Time RCE via Unescaped OpenAPI Default Values (CVE-2026-72716)

A newly disclosed advisory (GHSA-p4cg-3328-rvfg, CVE-2026-72716) reports that the code-generation tool orval is vulnerable to arbitrary JavaScript execution triggered simply by importing a generated file — no HTTP request or function call required.

What happened

According to the report, when orval generates zod validation schemas from an OpenAPI specification, it emits a query parameter's default value directly into a module-level JavaScript template literal (export const XDefault = \`<default>\`;) without escaping backticks or ${...} sequences. Because template literals evaluate ${...} as live JavaScript, a spec containing a default value shaped like v${<attacker JS>}w causes that expression to execute the moment the generated module is imported. The researcher verified this on orval 8.19.0, notes it survives default OpenAPI validation, and published a proof-of-concept (spec generator + reproduction script) demonstrating a marker write occurring purely from importing the generated schema. The report also flags that other default-bearing positions reach the same unescaped sink, so a single fix (proper escaping/encoding of default values) is expected to close multiple related paths.

Why it matters

This is a code-generation supply-chain risk rather than a runtime request-handling bug: any team that generates zod schemas with orval from an OpenAPI/Swagger description they don't fully control — vendor-supplied specs, third-party API contracts, CI pipelines that pull specs from external sources — could have attacker-controlled code execute as soon as the generated file is imported into a build or application. Because execution happens at import time, it can trigger in development environments, CI/CD build steps, or production startup, well before any API call is made.

What defenders should watch for

• Inventory where orval is used in your build/codegen pipeline and whether the OpenAPI specs it consumes originate from external, third-party, or otherwise untrusted sources.
• Treat OpenAPI/Swagger specs as untrusted input when they come from outside your organization — review or sanitize default fields before running codegen against them.
• Audit generated zod schema files for unexpected template-literal content (stray ${ sequences) as a quick manual/CI check while a fix is pending.
• Watch orval's repository/release notes for a patched version that properly escapes default values, and prioritize upgrading pipelines that ingest external specs.
• Consider running codegen steps in a sandboxed/isolated CI stage given the import-time execution vector.

This is developing, net-new intelligence — the advisory was published today and a fix is not yet confirmed as released. For full technical details and the maintainer's proof-of-concept, see the original GHSA advisory: GHSA-p4cg-3328-rvfg.