Orval Zod Client Generator: Header-Name Injection Enables Import-Time RCE (CVE-2026-71864)

A newly published GitHub Security Advisory (GHSA-6437-gxhq-pqv8, CVE-2026-71864) reports a code-generation vulnerability in orval, a popular tool that generates TypeScript API clients from OpenAPI specifications.

What was reported

According to the advisory, orval's Zod client generator emits each OpenAPI header parameter name as a double-quoted object key inside a generated zod.object({...}) schema, without escaping embedded double-quote characters. A header parameter name containing a " can close the string key early and inject a computed property key ([expr]) into the object literal. Because the generated schema is assigned at module scope (e.g. export const OpHeader = zod.object({...})), that expression executes the moment the generated file is imported — yielding arbitrary JavaScript/OS command execution at import time, not just at request-validation time. The report states this was verified on orval 8.19.0 with Node.js and includes a PoC (reproduce.sh / make_spec.py). The advisory also notes the same generation path is reused by orval's Hono client, and flags related-but-distinct sibling issues (schema property names, query parameter names) as separate reports.

Why it matters for defenders

This is a supply-chain-style risk rather than a runtime exploit against a deployed service: the danger lands on developers and CI pipelines that run orval against an OpenAPI spec they don't fully control or trust (third-party APIs, partner-provided specs, spec aggregators, or any spec ingestion pipeline). If an attacker can influence the spec's header parameter names, they can potentially achieve code execution as soon as the generated client module is imported — before any application logic runs. Exploit status is listed as PoC-public, so a working reproduction is already available, and no CVSS score has been assigned yet.

What defenders should watch for or do now

• Inventory whether your build/CI pipelines generate orval Zod (or Hono) clients from OpenAPI specs sourced from third parties, partners, or any input not fully trusted/reviewed.
• Treat OpenAPI spec ingestion as an untrusted-input boundary: review or sanitize specs (especially header parameter names) before running codegen against them, particularly in automated/CI contexts.
• Hunt for anomalous file writes, network calls, or process spawns occurring during npm install/build or immediately on import of generated client code in CI logs and build artifacts.
• Pin and monitor the orval package version, and watch for a patched release; the advisory's suggested fix is to properly JSON-stringify/escape parameter names used as object keys during code generation.
• As a general practice, review generated code output for unexpected computed property keys ([...]:) or non-literal expressions before trusting it in a build.

This is developing intel based on a single, recently published advisory — details such as an official patch version and CVSS scoring may still be forthcoming. For the full technical write-up and PoC, see the original advisory: GHSA-6437-gxhq-pqv8.