Critical flaw in orval's code generator can smuggle code into your TypeScript – but only from a hostile API spec

A newly disclosed vulnerability in orval, a widely used tool for turning OpenAPI specifications into TypeScript client code, has been rated critical with a CVSS score of 9.8. The NVD entry, published on 23 September, says versions before 8.29.0 fail to properly escape certain values when generating server code for the Hono framework — opening the door to code injection. That top-tier score demands attention, but it’s worth being clear about what this bug can and can’t do before anyone panics.

What the bug actually does

Orval’s @orval/hono generator takes an OpenAPI or Swagger specification and spits out matching TypeScript route handlers. According to NVD, the generator builds route paths using single-quoted string literals but doesn’t sanitise path values pulled straight from the spec. The relevant logic sits in orval’s own source, where path segments are dropped into generated code without escaping.

The upshot: if someone can control the OpenAPI document that orval is asked to process, they can craft a path value containing a stray quote mark and some extra JavaScript. When orval generates the code, that injected snippet ends up baked into the output file as executable code rather than as an inert string. Run that generated server, and the attacker’s payload runs with it.

This isn’t a bug that lets a stranger reach into your live API over the internet. It’s a build-time supply-chain problem: the danger lives in the generation step, not in a deployed server being probed remotely.

So who is actually at risk

The people who need to care are developers who point orval’s Hono generator at an OpenAPI spec they don’t fully control or trust — for instance, ingesting a third-party partner’s API definition, auto-generating code from a spec pulled from an external URL, or accepting specs uploaded by users in some kind of tooling pipeline. In those cases, a malicious spec author could smuggle code straight into your codebase the moment you run the generator.

If you’re using orval purely on specs you write yourself, or ones produced entirely in-house, this isn’t something a random attacker can exploit — there’s no untrusted input in the chain. It’s also irrelevant to anyone who doesn’t use orval’s Hono output at all, which rules out the vast majority of developers using its other generators, and everyone who isn’t writing backend code in the first place.

None of the sources here confirm active exploitation in the wild, nor do they give any indication of how many projects actually rely on the Hono generator specifically — orval itself is a substantial project, with 6.5k GitHub stars, but that popularity spans many output targets, not just this one.

What to do about it

NVD’s advisory implies the fix lands in orval 8.29.0, so teams using the Hono generator should update to that version or later and treat anything below it as exposed if untrusted specs are ever in play. Given the injection depends entirely on an OpenAPI document nobody vetted, the more durable fix is simply not running code generation against specs from sources you don’t control, regardless of which version you’re on.

The takeaway

A 9.8 score grabs attention, but this is a narrow, developer-tooling issue rather than a live threat to anyone’s running website or app. If you use orval’s Hono generator with third-party specs, update and be wary; if you don’t, this one passes you by entirely.