EUVD-2026-68727
GHSA-2jcc-mxv7-p3f9
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable via untrusted spec content; no privileges required to craft payload; scope changes because SSRF can compromise systems beyond the oasdiff process; no integrity or availability impact.
Primary rating from Vendor (https://github.com/oasdiff/oasdiff).
CVSS VectorVendor: https://github.com/oasdiff/oasdiff
Lifecycle Timeline
2DescriptionCVE.org
Summary
From v1.13.2 through v1.18.0, oasdiff did not enforce --allow-external-refs=false (library: openapi3.Loader.IsExternalRefsAllowed = false) when loading a spec from a git revision (the rev:path form, e.g. main:openapi.yaml). External $refs were resolved on that load path even when external refs were explicitly disabled, so the mitigation silently did not apply there.
Impact
A caller who set --allow-external-refs=false *specifically to safely process untrusted specs* remained exposed - on the git-revision load path only - to:
- SSRF via
$ref: "http://<internal-host>/…", and - Local file reads via
$ref: "/path"orfile://.
Affected callers:
- CLI:
oasdiff diff main:openapi.yaml HEAD:openapi.yaml --allow-external-refs=false(andbreaking/changelog/summary, and thegit-diff-driver) run over untrusted spec content. - Go library consumers of
github.com/oasdiff/oasdiff/loadthat setIsExternalRefsAllowed = falseand load from a git-revision source viaload.NewSpecInfo.
The file and URL load paths correctly enforced the setting; only the git-revision path was affected. Callers that left external refs at the default (true) are not in scope for *this* advisory.
Patches
v1.18.1 enforces the external-refs policy on the git-revision path (so --allow-external-refs=false now blocks external $refs there) and returns a dedicated exit code (123) when an external $ref is refused.
Workarounds
- Upgrade to v1.18.1, or
- Avoid the git-revision input form when processing untrusted specs with external refs disabled.
Notes
- Introduced in v1.13.2 (#832, which added
$ref-chain resolution on the git-revision path); fixed in v1.18.1 (#974, #975). - The permissive default (
allow-external-refs: true) and its zero-interaction exposure in CI via the GitHub Action is tracked separately in GHSA-fhj3-7267-7vv5 (oasdiff-action).
AnalysisAI
Security-control bypass in oasdiff v1.13.2-v1.18.0 silently negates the --allow-external-refs=false safety flag when loading OpenAPI specifications via the git-revision input form (rev:path, e.g. main:openapi.yaml), leaving callers exposed to SSRF and local file disclosure despite explicitly intending to sandbox untrusted spec processing. Malicious $ref URIs embedded in a spec - pointing to internal HTTP endpoints or local filesystem paths - are resolved on the git-revision load path even when the policy is set, while the file-path and URL load paths correctly enforce the restriction. No public exploit code has been identified at time of analysis and the vulnerability is not in CISA KEV; vendor-released patch v1.18.1 is available.
Technical ContextAI
oasdiff is a Go library and CLI tool (pkg:go/github.com_oasdiff_oasdiff) for diffing OpenAPI 3.x specification files, commonly deployed in CI/CD pipelines to detect breaking API changes. The root cause is CWE-73 (External Control of File Name or Path): user-controlled data - specifically, external $ref strings embedded in an OpenAPI spec - can direct the loader to resolve arbitrary file-system paths or network URLs. The git-revision loading path (load.NewSpecInfo with rev:path syntax), introduced in v1.13.2 via PR #832 to support $ref-chain resolution when diffing git revisions, omitted the IsExternalRefsAllowed check that the file-path and URL loading paths correctly applied. This created a silent gap: calling code that set openapi3.Loader.IsExternalRefsAllowed = false to block external $ref resolution received no error and no warning, while the loader continued resolving external references on the git-revision code path. SSRF payloads can target internal HTTP endpoints (including cloud metadata services such as AWS IMDSv1), and file-scheme or bare-path references can read files accessible to the oasdiff process.
RemediationAI
Upgrade to oasdiff v1.18.1, which enforces the --allow-external-refs=false policy on the git-revision loading path and returns a dedicated exit code (123) when an external $ref is refused; the fix is implemented in PRs #974 and #975 (https://github.com/oasdiff/oasdiff/pull/974, https://github.com/oasdiff/oasdiff/pull/975). If upgrading immediately is not possible, the primary workaround is to avoid the git-revision input form (rev:path syntax, e.g. main:openapi.yaml) when processing untrusted OpenAPI specs with external refs disabled; instead, export each revision to a temporary file and pass the file path to oasdiff - the file-path loading form correctly enforced the policy in all affected versions. This workaround adds a pipeline step (git show > tmpfile) and sacrifices the convenience of the native git-revision syntax. Callers operating entirely within a trusted content environment (no untrusted spec input) face materially lower risk but should still upgrade to eliminate the latent exposure. The GitHub Security Advisory at https://github.com/oasdiff/oasdiff/security/advisories/GHSA-2jcc-mxv7-p3f9 is the authoritative reference.
Same weakness CWE-73 – External Control of File Name or Path
View allVendor StatusVendor
SUSE
| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today