GHSA-6mr6-jvcr-2f25 — orval
Fix: orval-labs/orval#3692GHSA-6mr6-jvcr-2f25 is a SQL Injection vulnerability in orval. A fix is available for orval — see the affected versions and patch details below.
Orval: Import-time RCE via schema property name -> computed-property-key injection in the zod client
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6mr6-jvcr-2f25.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
orvalnpmDescription
Summary
orval's zod client emits each schema property name as a double-quoted key in the generated zod.object({...})
WITHOUT escaping the double quote. A " in a property name closes the key and lands in object-literal
context, where an injected computed property key [expr] is evaluated when zod.object({...}) runs -- which
is at MODULE IMPORT (the export const X = zod.object({...}) executes on load) -> import-time RCE. The
property name is a pure data field. Verified on orval 8.19.0 / Node. CWE-94 / CWE-95 / CWE-116.
Details
export const OpBody = zod.object({ "a":zod.string(),[require("fs").writeFileSync("PWNED","")]:zod.string(),"b": zod.string().optional() })
Sibling: the MSW mock uses a single-quoted key (' breakout, call-time) -- separate report. The TS interface key is a type (DoS only). Distinct from orval's $ref / route-path / server-url / zod-default findings.
PoC
reproduce.sh (+ make_spec.py) attached: a property name a":zod.string(),[require("fs").writeFileSync("<marker>","")]:zod.string(),"b -> zod.object; evaluating it (= importing the module) writes the marker. Verified on 8.19.0.
Impact
JavaScript / OS command execution (via child_process) at import time for anyone who generates an orval zod
client from an attacker-controlled spec and imports it. Estimated Critical, e.g.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.
Suggested fix
Escape the property name for the JS string key (JSON.stringify) in the zod.object key generation; never interpolate a raw property name adjacent to [ ] in object-literal position. maintainer-report.txt make_spec.py reproduce.sh
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | orval | all versions | 8.21.0npm install orval@8.21.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for orval, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update orval to 8.21.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6mr6-jvcr-2f25 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Frequently Asked Questions
Is GHSA-6mr6-jvcr-2f25 in your dependencies?
Find it across npm, including transitive dependencies.