Orval zod Client: Import-Time RCE via Unescaped Property Names in Generated Code (GHSA-6mr6-jvcr-2f25)

What happened

A newly published GitHub Security Advisory (GHSA-6mr6-jvcr-2f25, tracked as CVE-2026-71866) reports a critical code-generation flaw in orval, a popular npm package that generates TypeScript API clients from OpenAPI specs. According to the advisory, orval's zod client generator emits each schema property name as a double-quoted object key inside a generated zod.object({...}) call — without escaping embedded double-quote characters.

Because a property name is treated as pure data but rendered directly into source code, an attacker-controlled OpenAPI spec can supply a property name containing a " that breaks out of the key, followed by an injected JavaScript computed property key ([expr]). Since the generated export const X = zod.object({...}) executes at module import time, the injected expression runs as soon as the generated file is imported — no function call or runtime trigger needed. The report includes a working PoC verified against orval 8.19.0 on Node.js, demonstrating arbitrary file writes via require("fs").writeFileSync(...), implying broader command-execution potential via child_process. The advisory estimates this as Critical severity.

Why it matters for defenders

This isn't a runtime input-validation bug — it's a code-generation/build-time supply-chain risk. Any team that runs orval against an OpenAPI/Swagger spec they don't fully control or trust (third-party APIs, partner-supplied specs, specs pulled from external URLs in CI) is exposed. Because the malicious payload executes on import of the generated file, exploitation can happen silently during a build, a CI pipeline, or a developer's local dev server — before any application logic even runs. The advisory notes related but distinct findings in orval's MSW mock generation (single-quote breakout) and other injection points ($ref, route-path, server-url, zod-default), suggesting this generator has a broader pattern of unescaped interpolation worth scrutinizing as a class, not a single bug.

What defenders should watch for or do now

• Inventory whether your build/CI pipeline invokes orval against any OpenAPI spec sourced from outside your organization's direct control, and treat those specs as untrusted input until a patched orval release is available.
• Audit generated client output (especially zod.object({...}) blocks) for unexpected computed property keys ([...]) or unescaped quote characters in property names before committing generated code.
• In CI, consider running codegen steps in a sandboxed/ephemeral environment with no filesystem or network access beyond what's needed, since the exploit fires at import time and could otherwise reach build agents or CI credentials.
• Flag OpenAPI specs containing property names with embedded quote characters or unusual bracket syntax as suspicious during spec review or intake.
• Watch for orval's upstream fix (escaping property names via JSON.stringify as suggested in the advisory) and prioritize upgrading once released.

Developing intel

This item was published today and reflects a freshly disclosed GHSA advisory with a public PoC; full downstream impact (which orval versions are affected beyond 8.19.0, availability of a patched release) is still emerging. For the complete technical writeup and PoC details, see the original advisory: GHSA-6mr6-jvcr-2f25.