GHSA-6437-gxhq-pqv8: Code Injection
Summary
orval's zod client emits each header parameter name as a double-quoted key in the generated zod.object({...}) request-validation schema WITHOUT escaping the double quote. A " in the header parameter name closes the key and lands in object-literal context, where an injected computed property key [expr] is evaluated when zod.object({...}) runs -- at MODULE IMPORT (export const OpHeader = zod.object({...}) executes on load) -> import-time RCE. The header parameter name is a pure data field. Verified on orval 8.19.0 / Node.
Details
export const OpHeader = zod.object({ "a":zod.string(),[require("fs").writeFileSync("PWNED","")]:zod.string(),"b": ... })
Also affects the hono client (reuses zod generation). orval escapes values in zod arrays but not keys in zod.object. Sibling fields: schema property name, query parameter name (CVE-96) (separate reports). Distinct from orval's $ref / route-path / server-url / zod-default findings.
PoC
reproduce.sh (+ makespec.py) attached: a header parameter name that breaks the zod.object key and injects a computed key; evaluating it (= importing the module) writes the marker. Verified on 8.19.0.
Impact
JavaScript / OS command execution at import time for anyone who generates an orval zod client from an attacker-controlled spec and imports it.
Suggested fix
Escape the header parameter name for the JS string key (JSON.stringify) in the zod.object key generation; never interpolate a raw name adjacent to [ ] in object-literal position.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/orvalto a version that resolves this vulnerability.Fixed in 8.21.0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Projects that generate Zod clients with orval from API specifications containing attacker-controlled or otherwise untrusted header parameter names are exposed. The Hono client is also affected because it reuses the Zod generation path.
What does an attacker need to exploit it?
An attacker needs to cause a header parameter name containing a double quote and injected computed-property expression to be processed during client generation. The resulting generated JavaScript executes the expression when the generated module is imported.
What can be done if patching is not immediately possible?
Do not generate or import clients from untrusted API specifications. Review header parameter names before generation and reject names containing double quotes or other content that could break a generated object key.
How can I determine whether generated code is already dangerous?
Inspect generated Zod request-validation schemas for header objects with malformed quoted keys or unexpected computed property keys such as bracketed expressions. Treat affected generated modules as unsafe to import, because execution occurs at module load time.