CVE-2026-59149 in Mockoon
Summary
by MITRE • 07/09/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/09/2026
The vulnerability identified in Mockoon versions prior to 9.7.0 represents a critical path traversal flaw that undermines the application's security boundaries and allows unauthorized file access. This weakness exists within the file response functionality where the filePath parameter can embed request data, creating an attack vector that exploits insufficient path validation mechanisms. The core issue lies in the implementation of the getSafeFilePath function located in packages/commons-server/src/libs/server/server.ts which performs a simplistic prefix check using resolvedPath.startsWith(staticBaseDir). This approach fails to enforce proper path separator boundaries, allowing malicious actors to bypass directory restrictions through carefully crafted ../-escaped paths that maintain the required string prefix while accessing files outside the intended serving directory.
The technical execution of this vulnerability relies on the fundamental flaw in path validation logic that does not properly sanitize or normalize file paths before authorization checks. When a request contains a filePath parameter with directory traversal sequences, the system resolves the absolute path but only verifies that it begins with the static base directory prefix. This approach is inherently flawed because it does not account for the possibility that a malicious path like /var/www/mockoon/../etc/passwd could resolve to /var/etc/passwd which would still begin with /var/www/ if the staticBaseDir is set to /var/www, thereby bypassing the security check entirely. The vulnerability affects multiple service endpoints including HTTP sendFile operations, WebSocket connections, and callback mechanisms that may utilize file responses, providing attackers with multiple potential attack surfaces.
The operational impact of this vulnerability is severe as it allows unauthenticated clients to access sensitive files from sibling directories within the server's file system, potentially exposing configuration files, credentials, application code, or other confidential data. Attackers could exploit this weakness to read system files, database connection strings, API keys, or any content stored in adjacent directories that should normally be protected from external access. The vulnerability affects not only static file serving but also dynamic response generation through WebSocket and callback mechanisms, amplifying the attack surface significantly. According to CWE-22, this represents a Path Traversal vulnerability where insufficient input validation allows attackers to manipulate file paths and access unauthorized resources.
The mitigation for this vulnerability requires proper path normalization and boundary checking that ensures directory traversal attempts are properly detected and rejected. The fix implemented in Mockoon version 9.7.0 addresses this by strengthening the path validation logic to include proper path separator enforcement, ensuring that any attempt to traverse beyond the designated base directory is detected and blocked. Security practitioners should implement additional controls such as regular security audits of file access mechanisms, input sanitization for all dynamic file paths, and comprehensive testing of boundary conditions in path handling code. Organizations using Mockoon should immediately upgrade to version 9.7.0 or later and conduct thorough security assessments of their mock API configurations to ensure no other applications are similarly vulnerable. This vulnerability aligns with ATT&CK technique T1566 which involves the exploitation of vulnerabilities in software components to gain unauthorized access to systems and data resources.