GHSA-2h9g-j24r-h63g — orval
Fix: orval-labs/orval#3692GHSA-2h9g-j24r-h63g is a Code Injection vulnerability in orval. A fix is available for orval — see the affected versions and patch details below.
Orval: Import-time RCE via array-items default -> zod module-level template literal
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-2h9g-j24r-h63g.
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 schema generation emits the array-items default value as a module-level template literal (export const …Default = <default>;) without escaping ${ or the backtick. A default of the form v${<code>}w injects a live JavaScript expression evaluated when the generated zod schema module is imported, executing attacker-controlled code at import — no request or function call needed. Verified on Orval 8.19.0; survives default OpenAPI validation.
Details
export const …Default = `v${globalThis.ORVPWN()}w`; // ${...} = arbitrary JS expression, runs at import
Malicious input: an array property (string items) with a default of v${<attacker JS>}w. ${...} permits any JS expression.
Note: this is one of several default-bearing positions that reach the same unescaped zod template-literal sink; a single fix (escape default values) closes all of them, and a CNA may choose to consolidate the related reports.
PoC
reproduce.sh (+ make_spec.py) attached: generates the zod schema with default validation, bundles it, imports it, and shows a marker written at import. Verified on 8.19.0.
Impact
Code execution at import in any application that imports a zod schema module generated from an attacker-controlled or attacker-influenced OpenAPI description.
Suggested fix
Emit default values via a proper string-literal encoder (JSON.stringify, or escape backtick and ${ if a template literal must be used); never interpolate a spec value into a template literal. Apply to every default position. maintainer-report.txt make_spec.pyreproduce.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-2h9g-j24r-h63g 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-2h9g-j24r-h63g in your dependencies?
Find it across npm, including transitive dependencies.