EUVD-2026-42684
GHSA-8wqc-v2q8-vff2
Severity by source
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
UI:R reflects the operator must configure dynamic FILE routes; AV:N and PR:N because the attacker requires no credentials; C:H for arbitrary file read; I:N and A:N since no write or denial capability exists.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2Blast Radius
ecosystem impact- 3 npm packages depend on @mockoon/commons-server (3 direct, 0 indirect)
Ecosystem-wide dependent count for version 9.7.0.
DescriptionCVE.org
Mockoon provides way to design and run mock APIs. Prior to 9.7.0, a FILE response whose filePath embeds request data is confined by getSafeFilePath in packages/commons-server/src/libs/server/server.ts with resolvedPath.startsWith(staticBaseDir). That prefix test has no path-separator boundary, so a ../-escaped path whose absolute form string-prefixes the base directory passes, allowing an unauthenticated client to read files from sibling paths outside the served directory through HTTP sendFile, WebSocket, or callbacks. This issue is fixed in version 9.7.0.
AnalysisAI
Path traversal in Mockoon prior to 9.7.0 allows unauthenticated network clients to read arbitrary files from sibling paths outside the configured static serving directory. The vulnerability exists in the getSafeFilePath function in packages/commons-server/src/libs/server/server.ts, which enforces directory confinement using a bare string-prefix check (resolvedPath.startsWith(staticBaseDir)) without a path-separator boundary. Because any path whose absolute form begins with the base directory string - including sibling directories sharing a common prefix - passes this check, crafted ../-escaped values embedded in request data can escape the sandbox across HTTP sendFile, WebSocket, and callback channels. No public exploit code identified at time of analysis and no CISA KEV listing.
Technical ContextAI
Mockoon (CPE: cpe:2.3:a:mockoon:mockoon:*:*:*:*:*:*:*:*) is a developer-oriented tool for designing and running local mock APIs. It supports FILE response types where filePath can dynamically incorporate inbound request data such as path parameters or query strings. The server enforces a sandbox via getSafeFilePath in packages/commons-server/src/libs/server/server.ts using the pattern resolvedPath.startsWith(staticBaseDir). This check is vulnerable to CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) because String.prototype.startsWith performs character-by-character matching with no awareness of filesystem path separators. Concretely, if staticBaseDir is /app/mockdata, a resolved path of /app/mockdata-secrets/config.json - reachable via a ../-escaped traversal through a sibling directory - passes the prefix check, since that string does begin with /app/mockdata. The Node.js http.sendFile mechanism then serves the file to the requesting client.
RemediationAI
Upgrade Mockoon to version 9.7.0, which is confirmed as the vendor-released fix per the GitHub release at https://github.com/mockoon/mockoon/releases/tag/v9.7.0 and the advisory at https://github.com/mockoon/mockoon/security/advisories/GHSA-8wqc-v2q8-vff2. The upstream fix is tracked in pull request https://github.com/mockoon/mockoon/pull/2255 and commit b42bdfb7f82e83f0e81bea8e6fe41adf5ec82585. If immediate upgrade is not possible, disable any FILE response routes whose filePath value incorporates request-derived data (path parameters, query strings, headers) - static file paths are not affected. As an additional compensating control, restrict network access to the Mockoon server to trusted IP ranges only, preventing unauthenticated external clients from reaching the vulnerable endpoint. Both workarounds carry the trade-off of reducing Mockoon's core dynamic file-serving functionality.
Same weakness CWE-22 – Path Traversal
View allSame technique Path Traversal
View allShare
External POC / Exploit Code
Leaving vuln.today