GHSA-w7f9-wqc4-3wxr
HIGHMockoon has a Path Traversal and LFI in the static file serving endpoint
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@mockoon/commons-servernpm@mockoon/clinpmDescription
Summary
A mock API configuration for static file serving following the same approach presented in the documentation page, where the server filename is generated via templating features from user input is vulnerable to Path Traversal and LFI, allowing an attacker to get any file in the mock server filesystem. The issue may be particularly relevant in cloud hosted server instances
Details
In sendFileWithCallback(code) and sendFile(code) the filePath variable is parsed using TemplateParser
let filePath = TemplateParser({
shouldOmitDataHelper: false,
// replace backslashes with forward slashes, but not if followed by a dot (to allow helpers with paths containing properties with dots: e.g. {{queryParam 'path.prop\.with\.dots'}})
content: routeResponse.filePath.replace(/\\(?!\.)/g, '/'),
environment: this.environment,
processedDatabuckets: this.processedDatabuckets,
globalVariables: this.globalVariables,
request: serverRequest,
envVarsPrefix: this.options.envVarsPrefix
});
The path extracted from the request parameters used when composing the final file path is not sanitized and is vulnerable to path traversal exploits (e.g. ../../../../../etc/passwd)
PoC
Test setup
The issue has been tested with mockoon-cli, using the Docker image mockoon/cli:latest
# Folder setup
mkdir mockoon-test
cd mockoon-test
# put config.json in mockooon-test dir
mkdir static
# Run container
docker run -d --mount type=bind,source=./config.json,target=/data,readonly -v ./static:/static -p 3000:3000 mockoon/cli:latest -d data -p 3000
Payload to reproduce
Browsing directly to http://localhost:3000/static/%2F..%2F..%2F..%2F..%2F..%2Fetc%2Fpasswd is going to display the /etc/passwd file in the container filesystem
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @mockoon/commons-server | all versions | 9.2.0 |
| 📦npm | @mockoon/cli | all versions | 9.2.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @mockoon/commons-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @mockoon/commons-server to 9.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w7f9-wqc4-3wxr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w7f9-wqc4-3wxr is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w7f9-wqc4-3wxr. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w7f9-wqc4-3wxr in your dependencies?
O3 detects GHSA-w7f9-wqc4-3wxr across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.