Orval npm RCE Advisories: Upgrade to 8.22.0

Short answer: Three Orval npm security advisories disclosed on September 2, 2026 affect projects that generate clients from attacker-controlled or attacker-influenced OpenAPI documents. Two flaws can place executable JavaScript in generated Zod modules, while a third can make the build host fetch remote URLs or read files outside the specification directory. Upgrade orval to 8.22.0 or later, regenerate clients from a trusted specification, and investigate any untrusted generation jobs.

The advisories cover CVE-2026-71866, CVE-2026-72716, and CVE-2026-62680. The first two are rated critical by GitHub; the third is high severity. They are vulnerabilities in a legitimate package, not evidence that the Orval package itself was taken over.

Which Orval versions are affected?

The practical remediation target is Orval 8.22.0 or newer. Version 8.21.0 fixes the two code-injection paths, but it does not include the complete fix for the unrestricted $ref issue.

How do the Orval npm RCE flaws work?

Orval turns OpenAPI descriptions into application code. That makes escaping and trust boundaries especially important: data from a specification must remain data when it is written into generated JavaScript or TypeScript.

In CVE-2026-71866, a specially crafted schema property name can break out of the string context used for a generated Zod object key. The injected expression is evaluated as the generated module loads. In CVE-2026-72716, the vulnerable generator writes a query parameter's default value into a JavaScript template literal without safely escaping a backtick or the ${...} expression syntax. That also allows attacker-controlled JavaScript to run when the generated Zod module is imported.

This is an important exposure condition: simply depending on Orval is not the same as being exploited. An attacker must influence the OpenAPI input, and the dangerous generated output must reach an execution path. However, teams often generate clients automatically in CI, accept partner specifications, or pull specifications from remote endpoints. A generated module may then be imported by tests, builds, development tooling, or the application itself.

What can the unrestricted $ref flaw expose?

CVE-2026-62680 concerns how vulnerable Orval versions resolve OpenAPI $ref values. A hostile specification can point a reference at an HTTP or HTTPS URL, causing the developer workstation or CI runner to make the request. That creates a server-side request forgery path from the build environment. The same resolver can follow absolute or out-of-tree local paths, causing local file contents to be read and incorporated into generated output.

The primary advisory describes SSRF plus local and remote file inclusion, not direct code execution through this specific flaw. Its impact still depends heavily on the build environment. A CI runner may be able to reach internal services, cloud metadata endpoints, source-control systems, or files containing configuration and credentials. If generated output is uploaded as an artifact, committed, or printed in logs, locally read data may travel farther than expected.

How can you check whether your project is exposed?

1. Find every installed Orval version. From the project root, run npm ls orval --all. For pnpm use pnpm why orval; for Yarn use yarn why orval.
2. Inspect lockfiles, including old branches. Search package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, and yarn.lock for Orval. A clean current install does not prove a vulnerable version never ran in CI.
3. Locate code-generation workflows. Search package scripts and CI definitions for orval, npx orval, or wrapper scripts. Identify whether the OpenAPI input is local, downloaded, submitted by users, supplied by partners, or taken from pull requests.
4. Review runs since the input became untrusted. Check build logs, network telemetry, generated-code diffs, and artifacts for unexpected outbound requests, surprising file content, or unexplained JavaScript expressions.
5. Check whether generated Zod modules executed. Determine whether tests, bundlers, type-generation steps, preview builds, or deployed applications imported output created from an untrusted specification.

A quick version check is useful, but exposure is a combination of version, input provenance, and execution. Our broader npm package safety checklist explains how to combine advisory checks with publisher, release, and install-time signals.

How should developers remediate the Orval advisories?

1. Upgrade to 8.22.0 or later. Update the direct dependency with npm install --save-dev orval@^8.22.0, or use the equivalent command for your package manager. If Orval is transitive, update the parent tool or apply an override after testing.
2. Regenerate from a trusted OpenAPI source. Delete suspect generated files and rerun generation after upgrading. Review the resulting diff before committing or deploying it.
3. Constrain specification sources. Pin remote specifications to approved hosts and authenticated sources. Do not run code generation automatically on arbitrary pull-request content or user-submitted schemas.
4. Reduce build-runner reach. Block unnecessary outbound traffic, restrict access to cloud metadata and internal services, and avoid exposing deployment credentials to code-generation jobs.
5. Respond according to observed execution. If an untrusted specification was processed and generated code was imported, treat the runner or workstation as potentially compromised. Preserve evidence, rebuild from a known-good image, and rotate credentials accessible to the affected process. If only the $ref path was reachable, investigate outbound connections and possible file disclosure.

Upgrading closes the vulnerable code paths, but it does not undo a previous generation run or revoke secrets that may already have been exposed.

How does a registry firewall help?

A registry firewall can keep known-vulnerable package versions from reaching developer machines, CI jobs, and coding agents. InstallSafe sits at the npm install boundary, uses OSV.dev advisory data, blocks flagged versions, and serves approved packages byte for byte. Teams can also use the free npm package scanner to check a package before changing a project.

For these advisories, an advisory-aware policy can deny affected Orval versions once the records are available in the feed. That is useful for preventing a downgrade, catching a forgotten repository, or protecting automated dependency installs. It complements repository and CI vulnerability scanning, which helps locate affected versions already present in a dependency graph.

A registry firewall is not a complete fix for unsafe code-generation inputs. It cannot make a hostile OpenAPI document trustworthy, and advisory-backed controls do not claim to detect zero-hour vulnerabilities before disclosure. Pair version enforcement with trusted input sources, egress restrictions, least-privilege CI, generated-code review, and incident-response procedures.

What should security teams do today?

First, inventory Orval across source repositories and build images. Prioritize any project below 8.21.0 because two advisories describe import-time code execution, then move every project below 8.22.0 to the fully fixed line. Next, map where specifications originate and whether generated modules execute automatically. Finally, review recent generation jobs that handled content outside your direct control.

The cleanest long-term control is to treat API specifications as build inputs with the same trust requirements as source code. Pin them, authenticate their source, review changes, limit what generators can reach, and prevent vulnerable tool versions from entering the environment.

FAQ

Is the Orval npm package compromised?

No compromise is alleged in these advisories. They describe vulnerabilities in how legitimate Orval versions process OpenAPI data and generate code.

What Orval version fixes all three advisories?

Upgrade to Orval 8.22.0 or later. Version 8.21.0 fixes the two import-time code-injection vulnerabilities, while 8.22.0 also fixes the unrestricted $ref issue.

Am I vulnerable if Orval is only a devDependency?

Potentially. The risky activity occurs during generation and when generated modules are imported, so developer machines and CI runners matter even if Orval never ships in production.

Does npm audit prove that no exploitation occurred?

No. An advisory scan can identify a known vulnerable version, but it does not reconstruct which specifications were processed, which network requests occurred, or whether generated code executed.

Do I need to rotate credentials?

Rotate credentials if untrusted OpenAPI input was processed and you find evidence of code execution or sensitive file access, or if you cannot confidently rule it out on a privileged runner. A version match alone is not proof that secrets were exposed.