That 9.8 CVE in a popular API code generator needs a very specific victim

A new entry has landed on the National Vulnerability Database with the kind of score that normally sets off alarm bells: CVSS 9.8, “critical”, filed as CVE-2026-108551. The affected project is openapi-typescript-codegen, a fairly popular open-source tool (3.4k GitHub stars) that developers use to auto-generate TypeScript or JavaScript API clients from an OpenAPI specification file. Before anyone panics about every app built with it, it’s worth separating what’s actually been shown from what the number implies.

What the bug actually does

Per the NVD summary, versions up to and including 0.31.0 will happily take values from an OpenAPI document — things like the server URL or version string — and drop them straight into generated code without escaping them. You can see the mechanism in the project’s own template file, OpenAPI.hbs, where fields such as server and version are inserted using Handlebars’ triple-brace syntax ({{{ server }}}). That triple-brace is Handlebars shorthand for “don’t bother escaping this” — fine if the input is trustworthy, risky if it isn’t.

So in plain terms: if someone can control the contents of the OpenAPI spec that a developer feeds into this tool, they can potentially smuggle executable JavaScript into the generated client code. That’s a genuine code-injection vector, hence the high severity score.

So who is actually at risk

This is not a vulnerability in a live, running web application that strangers can poke at over the internet. It’s a flaw in a build-time code generator. To be exploited, someone has to:

• get a malicious or tampered OpenAPI document in front of a developer,
• have that developer run openapi-typescript-codegen against it, and
• have nobody notice the resulting generated code before it’s compiled, shipped or executed.

That’s a meaningfully narrower attack surface than “critical, 9.8” tends to suggest on its own. It matters most in setups where OpenAPI specs come from third parties, automated pipelines, or anywhere the source document isn’t fully trusted — think internal tooling pulling specs from partner APIs, or CI jobs that regenerate clients automatically from an external source. Ordinary end users of apps built with this tool are not directly exposed; this is a supply-chain-style risk aimed at the development process, not a remotely exploitable hole in finished software.

What we don’t yet know, because none of the published sources say so: whether there’s a patched release beyond 0.31.0, and whether this is being actively exploited anywhere. The CVE describes the mechanism, not a confirmed incident.

What to do about it

If your team uses openapi-typescript-codegen as part of a build or CI pipeline, the sensible move is to check which version you’re on and keep an eye on the project’s GitHub repository for a fix. More importantly, treat any OpenAPI document you didn’t write yourself as untrusted input — don’t auto-generate client code from specs sourced from unverified third parties without review.

The takeaway

A 9.8 score grabs attention, but this is a developer-tooling flaw that needs a hostile spec file and a trusting pipeline to matter. It’s a legitimate reason for teams using this generator to tighten how they handle external OpenAPI documents — not a reason for anyone else to worry about apps they already use.