CVE-2026-59149: Mockoon Path Traversal Leads to Unauthorized File Disclosure

Technical summary

The vulnerability exists in the getSafeFilePath function within Mockoon's server-side file-handling logic. The function validates file paths using a simple prefix test: resolvedPath.startsWith(staticBaseDir). This check lacks a path-separator boundary condition, enabling an attacker to craft relative paths (using ../ sequences) that, when resolved to their absolute form, pass the prefix check by coincidence while actually pointing outside the intended directory. An attacker can exploit this through HTTP sendFile operations, WebSocket messages, or callback mechanisms. The root cause is a classic path-traversal weakness (CWE-22) compounded by improper restriction of path navigation (CWE-23). The fix enforces proper boundary validation in version 9.7.0.

Business impact

For teams using Mockoon in development and testing environments, this vulnerability could lead to unauthorized disclosure of configuration files, credentials, source code, or other sensitive data stored on the same machine. If Mockoon instances are exposed to untrusted networks or used in shared development environments, an attacker can exfiltrate information without authentication. The impact is confined to confidentiality; data integrity and availability are not affected. However, exposed credentials or secrets could facilitate secondary attacks on downstream systems.

Affected systems

Mockoon versions prior to 9.7.0 are affected. The vulnerability impacts the mock API server runtime regardless of the host operating system. It affects all FILE response types that embed request data into the filePath parameter, and can be triggered via HTTP, WebSocket, or callback protocols supported by Mockoon.

Exploitability

The vulnerability is relatively straightforward to exploit from a technical perspective—an attacker needs only to craft a request with a malicious path parameter. However, exploitation does require user interaction: a victim must visit a link or send a request that invokes the mock server. The CVSS vector reflects this (UI:R). No authentication is needed. An attacker must have network access to the Mockoon instance, which in typical development scenarios means local network or internet access depending on where the mock server is running. Proof-of-concept tools are not publicly known to be circulating.

Remediation

Upgrade to Mockoon version 9.7.0 or later. The patched version includes corrected path validation logic that enforces proper directory boundaries. Before upgrading, apply network-level controls to restrict access to Mockoon instances to trusted developers only; avoid exposing mock servers directly to the internet.

Patch guidance

Update Mockoon to version 9.7.0 or any later release. Consult the official Mockoon release notes and advisory for specific installation instructions. If you manage Mockoon via package managers (npm, Docker, etc.), standard update procedures should apply. Verify your update by checking the version reported by the Mockoon UI or CLI. Test your mock API endpoints after patching to ensure configurations remain intact.

Detection guidance

Monitor web server and application logs for unusual file-access patterns, particularly requests containing path-traversal sequences (../, ..\ variations) in parameters that map to file paths. In Mockoon, examine incoming FILE response requests for suspicious filePath values. If Mockoon is exposed to external networks, implement intrusion detection signatures for path-traversal attempts. Check access logs for requests attempting to access files outside the designated mock API directory. Correlate timestamps with any unauthorized file access incidents on the host system.

Why prioritize this

This vulnerability merits prompt patching despite its CVSS score of 6.5 (MEDIUM) because it enables unauthenticated information disclosure in development and testing environments where secrets and source code often reside. The fix is straightforward and low-risk. Organizations should prioritize patching if Mockoon instances handle sensitive test data or run in multi-tenant environments. However, it is not an emergency if Mockoon is confined to isolated development networks with trusted users.

Risk score, explained

The CVSS 3.1 score of 6.5 reflects a network-accessible vulnerability with no authentication requirements, but high impact on confidentiality. The score is tempered by the requirement for user interaction (UI:R), which limits attack scalability. The scope is unchanged (a single Mockoon instance), and there is no impact on integrity or availability. Organizations with strict data-access controls in development environments or those running Mockoon only on isolated networks should assess their own risk as potentially lower.

Frequently asked questions