Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-62680

CVE-2026-62680: Orval TypeScript Client SSRF Vulnerability

CVE-2026-62680 is a Server-Side Request Forgery flaw in Orval that allows attackers to trigger requests to internal services and read local files through malicious OpenAPI specifications. This article covers technical details, affected versions, impact, and mitigation strategies.

Updated:

CVE-2026-62680 Overview

CVE-2026-62680 affects Orval, a code generator that produces type-safe TypeScript clients from OpenAPI v3 and Swagger v2 specifications. Versions prior to 8.22.0 resolve external $ref values without an allowlist or confinement to the input directory. An attacker who supplies a crafted OpenAPI description can force the developer or continuous integration (CI) host to issue outbound HTTP requests to attacker-selected or internal services. The flaw also allows reading absolute or out-of-tree local files and inlining untrusted remote schemas into the generated client code. The vulnerability is classified under CWE-22 Path Traversal.

Critical Impact

Processing an attacker-controlled OpenAPI specification can cause server-side request forgery (SSRF), local file disclosure, and injection of untrusted schema content into generated TypeScript clients used downstream in production applications.

Affected Products

  • Orval versions prior to 8.22.0
  • The vulnerable component is packages/orval/src/import-specs.ts external reference loading
  • Developer workstations and CI/CD pipelines that run orval against untrusted OpenAPI descriptions

Discovery Timeline

  • 2026-08-19 - CVE-2026-62680 published to the National Vulnerability Database (NVD)
  • 2026-08-19 - Last updated in NVD database
  • Fix released in Orval v8.22.0 via Pull Request #3723

Technical Details for CVE-2026-62680

Vulnerability Analysis

Orval parses OpenAPI documents and follows $ref pointers to assemble a complete schema before generating client code. The pre-8.22.0 implementation in packages/orval/src/import-specs.ts dereferences both remote URLs and local file paths found inside $ref values without validating the destination. There is no allowlist of trusted domains and no confinement of local paths to the input directory. When a developer or CI job feeds an attacker-controlled specification into orval, the tool follows every reference blindly. This turns a build-time code generation step into a network and filesystem access primitive under attacker control.

Root Cause

The root cause is missing input validation on external $ref targets during specification loading. Orval trusted any URI or path present in the input document. The patched code introduces an explicit externalRefs.allow allowlist in the configuration schema, forcing users to opt in to specific external sources before resolution proceeds.

Attack Vector

An attacker delivers a malicious OpenAPI or Swagger document to a victim through a pull request, dependency, shared schema repository, or public catalog. When the victim runs orval locally or in CI, embedded $ref values point at internal HTTP services, cloud metadata endpoints, or absolute file paths like /etc/passwd or ~/.ssh/id_rsa. Orval fetches and inlines that content, exfiltrating file contents into the generated client or triggering SSRF against internal infrastructure.

typescript
// Patch excerpt from packages/core/src/types.ts (v8.22.0)
// Introduces the externalRefs allowlist that gates $ref resolution
      domains: string[];
      headers: Record<string, string>;
    }[];
    externalRefs?: {
      allow?: string[];
      // TODO: add `deny?: string[]` when users need "allow all except X"
    };
  };
}

Source: orval-labs/orval commit 23786c0

typescript
// Patch excerpt from packages/core/src/generators/options.ts (v8.22.0)
// Hardens property lookup against prototype pollution during option parsing
      value != null &&
      typeof value === 'object' &&
      !Array.isArray(value) &&
-      Object.hasOwn(objectParamStrategies, key)
+      Object.prototype.hasOwnProperty.call(objectParamStrategies, key)
    ) {
      const objectStrategy = objectParamStrategies[key];
      const entries = Object.entries(value as Record<string, unknown>);

Source: orval-labs/orval commit 23786c0

Detection Methods for CVE-2026-62680

Indicators of Compromise

  • Outbound HTTP requests from developer workstations or CI runners to unexpected internal IP ranges, cloud metadata endpoints such as 169.254.169.254, or unfamiliar external hosts during orval execution.
  • Generated TypeScript client files containing schema fragments, comments, or type names that do not match the intended API specification.
  • Presence of absolute paths or remote URLs inside $ref fields of input OpenAPI documents pulled from untrusted sources.

Detection Strategies

  • Audit repositories for orval invocations in package.json scripts and CI pipelines, then verify the source of every OpenAPI specification consumed.
  • Diff generated client output before and after Orval upgrades to identify schema fragments injected from external references.
  • Enable egress logging on build agents and alert on any HTTP request initiated by node processes running orval.

Monitoring Recommendations

  • Monitor CI/CD network telemetry for connections to link-local, RFC1918, or unapproved external addresses during code generation stages.
  • Track dependency updates that pin orval and fail builds when the installed version is below 8.22.0.
  • Log filesystem reads outside the project directory by build tooling using auditd, eBPF, or equivalent host telemetry.

How to Mitigate CVE-2026-62680

Immediate Actions Required

  • Upgrade Orval to version 8.22.0 or later across all projects, developer environments, and CI images.
  • Review recent OpenAPI specifications processed by orval for suspicious $ref values pointing to external URLs or absolute paths.
  • Rotate any credentials, tokens, or SSH keys that resided in files potentially readable by the build user on affected hosts.

Patch Information

The fix is available in Orval v8.22.0. The change gates external $ref resolution behind an explicit externalRefs.allow allowlist as delivered in Pull Request #3723 and commit 23786c0. Full technical details are in GitHub Security Advisory GHSA-cxq5-97v7-87j8.

Workarounds

  • Run orval only against OpenAPI specifications from trusted, first-party sources until upgrade completes.
  • Execute code generation inside isolated containers with no network egress and read-only mounts limited to the project directory.
  • After upgrading, configure the new externalRefs.allow option with a minimal list of trusted domains needed by your specifications.
bash
# Upgrade Orval and pin it in package.json
npm install --save-dev orval@^8.22.0

# Verify installed version
npx orval --version

# Example hardened orval.config.ts snippet
# module.exports = {
#   api: {
#     input: './openapi.yaml',
#     output: './src/api',
#     externalRefs: {
#       allow: ['https://schemas.example.com']
#     }
#   }
# };

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.