CVE: CVE-2026-22785
Severity: Critical
CVSS v4.0 Score: 9.3 — Remote, unauthenticated, high impact on code generation workflows
Exploitability: High potential if attacker can influence input
Exploit Availability: Public proof-of-concept not widely published yet
Official Patch / Upgrade: Details provided below.

What the Vulnerability Actually Is

orval is a popular tool developers use to turn OpenAPI specifications (the API “contract”) into actual TypeScript/JavaScript clients or server code for APIs. If you’ve ever used orval to auto-generate code from an OpenAPI YAML/JSON file, this applies.

In versions before 7.18.0, when orval built server code from an OpenAPI file, it took something called the summary field straight from that API document and put it into a block of source code without any safety checks.

Normally, summary fields are free text like “Gets pet data”, but because the generator didn’t escape or sanitize that text, an attacker who can control or modify a spec could put something like:

summary: Finds pets.'; malicious_code_here(); //

…inside the spec’s summary field. When orval’s server generator stitches that into code, the malicious text ends up being run as real code later on when the generated server runs — essentially giving remote code execution. The attacker doesn’t need any credentials; they just need to influence the OpenAPI input.

How This Can Be Exploited

This flaw doesn’t magically go off by itself; exploitation happens in these broad scenarios:

1. Pulling an Untrusted API Spec

If a developer or system pulls an OpenAPI file from somewhere not trusted (a third-party repo, a shared API definition hub, or user-provided spec) and then runs orval on it, the malicious summary gets built into the generated code.

2. CI/CD Builds

Build pipelines that automatically run orval on specs could pick up a poisoned file from a fork, branch, or upstream source. Because CI typically runs with build privileges and may have access to secrets, this could lead to high-impact execution.

3. Local Dev Machines

A developer who runs code generation on an infected spec without checking it first effectively builds malicious code into an app that might later get committed and deployed.

Once the attacker’s injected code lands in generated artifacts, it could:

• Spawn a reverse shell
• Drop malware or ransomware into build outputs
• Exfiltrate API keys or credentials used during code generation
• Modify subsequent commits or releases

All of that happens because the code injection turns into actual executable code when the generated server is run.

Why It’s Serious

• No authentication needed: You don’t need to login or have credentials. Just getting the vulnerable tool to process a hostile spec is enough.
• Wide use in modern app stacks: Lots of teams use OpenAPI tooling in automated build pipelines.
• Supply-chain angle: Poisoned API specs can arrive via pull requests, submodules, or shared API schemas.
• Execution with privileges: If build agents have access to secrets or deploy tokens, an attacker’s code can use them.

This isn’t just “bad input text” — it lets someone write executable code into your application artifacts.

Is There a Public PoC?

As of now, there’s no widely recognized public exploit toolkit or proof-of-concept script floating around labeled specifically for this CVE. However:

• Security research on similar code-injection bugs shows how easy it is to craft malicious OpenAPI summaries.
• There are example OpenAPI specs that embed payload text designed to break out of string handling. The underlying issue is well understood.
• Even without a polished PoC, a skilled developer could recreate the injection scenario quickly.

So even though you might not find a “CVE-exploit.zip” online yet, the vulnerability is real, reproducible, and conceptually simple.

How to Detect Attempts or Exploitation

You can’t detect this purely with network traffic like a normal exploit — this happens as part of a build/code generation process. Detection focuses on build logs, repo activity, and generated code review.

Here are real things to watch for:

Logs and Build Artifacts

• CI logs showing the invocation of orval on a spec pulled from an external URL or unfamiliar branch.
• Generated server code that suddenly contains unusual syntax in summary-derived blocks — especially backticks, quotes, semicolons, or child process calls.
• Build jobs that execute unknown commands or call shell utilities they usually don’t.

Continuous Integration Alerts

Set alerts for:

• Unusual orval runs triggered by merge requests from outside contributors.
• New or changed OpenAPI spec files with modified summary lines.
• Build failures after new spec commits — could be malformed or malicious content.

Repository Scans

In your code repositories:

• Look at diffs for lines in OpenAPI specs with punctuation that doesn’t belong (e.g., ';, backticks, embedded eval).
• Scan generated code folders for strings that shouldn’t be there.

Developer Workstations

Use static analysis on workstations or build servers to detect when generated code contains patterns that aren’t normal (like shell execution or process spawning calls).

Sigma-style Detection Rules

You can write detection rules that watch for:

• orval invocation logs in CI with external spec URLs.
• Generated code patterns with suspicious literal escapes.
• Shell or process commands appearing immediately after code generation.

Detection is about process hygiene — stop dangerous specs before code is executed.

How to Protect Yourself Right Now

1. Upgrade immediately
Upgrade all tooling that uses orval to version 7.18.0 or later — that version includes the fix that properly escapes the summary field so injection isn’t possible.

2. Treat API specs like code
Don’t blindly trust API definitions. Review them, especially any that come from outside teams or third-party sources.

3. Vet build pipelines
Make sure your CI only uses local, committed API specs that you trust. Avoid downloading specs at build time from unknown sources.

4. Use sandboxed build environments
Run code gen in containers or isolated tools that have no credentials and no direct access to deploy systems.

5. Code review generated outputs
Before generated code is merged or used in builds, scan or review for suspicious code patterns.

6. Lock down access
Even if code is malicious, good privilege boundaries (least privilege, no access to secrets) can limit what a compromised build can do.

How This Was Fixed

The orval team corrected the issue in version 7.18.0 by changing how the “summary” field is processed: instead of blindly pasting it into code, they now validate and escape it so special characters cannot break out of strings and trigger injected commands.

Official Patch/Upgrade Link:
🔗 https://github.com/orval-labs/orval/security/advisories/GHSA-mwr6-3gp8-9jmj

Final Takeaway

If someone can get you to generate code from a special OpenAPI file — especially one they uploaded or helped edit — and your tooling uses an old orval version, they can slip in text that turns into real code. That code runs later when someone runs or tests the generated server, and that’s how a hostile actor gets code execution.