orval: 3 Code Injections at 9.8 via an OpenAPI Spec — Fixed in 8.29.0

Three vulnerabilities rated 9.8 were published on September 23, 2026 against orval, a widely used TypeScript code generator that produces API clients from an OpenAPI specification. Fix: 8.29.0.

These CVEs are unremarkable on their own — forgotten escaping. What deserves an article is the threat model they reveal, which many teams have never considered: an OpenAPI specification is code.

The Three CVEs

Shared vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

The mechanism, three variants

CVE-2026-96754 — an apostrophe in a path segment:

fails to escape OpenAPI path values in single-quoted route literals. Attackers can craft an OpenAPI document with an apostrophe in a static path segment to inject arbitrary JavaScript code that executes when the generated TypeScript module is imported.

CVE-2026-96755 — a ${...} expression in a default value:

converts OpenAPI schema defaults into template literals. Attackers can inject arbitrary JavaScript expressions via schema defaults containing ${...} syntax, which are executed at module scope when the generated code is built or imported.

CVE-2026-96759 — a booby-trapped operationId:

fails to escape the operationId parameter [...]. Attackers can inject arbitrary JavaScript code through a crafted operationId in an OpenAPI specification that executes when generated hooks are called.

It's the same error in three places: a value from the spec is pasted into generated code without escaping. For a code generator, that's the equivalent of SQL injection.

The Real Question: Where Does Your Spec Come From?

The severity depends entirely on this.

If you generate from your own spec, written and reviewed by your team, the risk is low: the attacker would already need to be able to modify your repository.

If you generate from a third party's spec — a partner, a SaaS vendor, a public API, a URL fetched at build time — you're running code chosen by that third party. And many projects do exactly that: an orval script downloading the vendor spec on every build to stay in sync.

In that case, compromising the server that publishes the spec is enough to inject code into every application that generates its client from it.

Where that code runs

That's what makes these CVEs serious:

• On the developer's machine, during generation or import — with access to their git, npm and cloud credentials
• In CI, during the build — with access to pipeline secrets
• In users' browsers for CVE-2026-96759: TanStack Query hooks are part of the front-end code shipped to production. The injected code runs for every visitor, in your application's context.

Checking Exposure

# Installed version
npm ls orval
npx orval --version

# Where does the spec come from? Look for remote sources in the orval config
grep -rnE "input|target" orval.config.* | grep -iE "https?://"

If the second command returns URLs, you generate from an external source.

Mitigation

1. Update orval to 8.29.0 or later, then regenerate the client code: code already generated with a vulnerable version stays vulnerable until it's reproduced.
2. Review the currently committed generated code if your spec comes from a third party: look for unexpected constructs in route paths, default values and operation metadata.
3. Stop downloading the spec on every build. Version a copy of the spec in your repository, and route its updates through code review like any other change.
4. Treat generators as compilers of untrusted input: orval, openapi-generator, GraphQL or protobuf generators all take input that determines the code they produce.

Why Continuous Monitoring of Build Dependencies Matters

A code generator appears in no production inventory — it's a development dependency. Yet it writes code that ships to production. Three 9.8 CVEs on such a tool are a reminder that the software supply chain starts well before npm install in production.

With cveo.tech, inventory your critical dependencies — build tools included — and get alerted whenever a critical CVE affects them.