Orval Zod Client Generator: Import-Time RCE via Unescaped Query Parameter Names (CVE-2026-71865)

A newly published GitHub Security Advisory (GHSA-653q-5476-x79g, tracked as CVE-2026-71865) discloses an import-time remote code execution vulnerability in orval, a popular OpenAPI-to-TypeScript client generator for the npm ecosystem.

What happened

According to the advisory, orval's zod client generator emits each API query parameter name as a double-quoted object key inside a generated zod.object({...}) schema, without escaping embedded double-quote characters. Because the query parameter name originates from the OpenAPI spec being processed, an attacker who controls that spec can craft a parameter name containing a " that closes the object key early, followed by a JavaScript computed property key ([expr]). That expression is evaluated as soon as the generated module is imported — since the schema is built at the top level via export const OpQueryParams = zod.object({...}) — resulting in arbitrary JS/OS command execution at module load time, not at request-handling time. The reporter states this was verified against orval 8.19.0 on Node, with a proof-of-concept (a spec-generation script and reproduction shell script) attached to the advisory. The advisory also notes the same code path is reused by orval's hono client, and lists sibling issues (schema property names, header parameter names) as separate, related reports. The exploit status is listed as public PoC.

Why it matters

This is not a runtime-input vulnerability — it's a supply-chain-adjacent code generation flaw. Any workflow that generates an orval zod (or hono) client from an untrusted or attacker-influenced OpenAPI/Swagger specification — for example, ingesting a third-party API spec, a spec fetched from an external partner, or a spec contributed via a pull request — and then imports the generated code, could trigger arbitrary code execution the moment that file is loaded, with no further action required. This is particularly relevant for CI/CD pipelines, codegen-on-build setups, and any team that treats OpenAPI specs as semi-trusted input rather than fully trusted internal artifacts.

What defenders should do now

• Inventory usage of orval in your build/codegen pipelines and identify whether generated zod or hono clients are produced from specs that are not fully first-party/trusted.
• Treat any OpenAPI spec ingested from external sources (partner APIs, marketplaces, user-submitted integrations) as untrusted input to the codegen step — review or sandbox codegen runs rather than executing them with full CI privileges.
• Audit generated client output for anomalous object keys or unexpected bracket/computed-property syntax in zod.object({...}) blocks before importing or committing generated code.
• Watch for unexpected file writes, process spawns, or network activity occurring immediately at build/import time in CI runners that execute codegen — that is the trigger point for this class of bug, not request handling.
• Check for an upstream orval patch that escapes parameter names via proper JSON string encoding before they are interpolated as object keys, and upgrade once available.

This is developing, net-new intelligence based on a single vendor security advisory published today; details such as the fixed version and full exploitation constraints may evolve. For the original report, PoC, and maintainer discussion, see the GitHub Security Advisory.