CVE-2026-59149: Sibling Directory Path Traversal in Mockoon Backend Server

CVE-2026-59149 represents a path traversal vulnerability in @mockoon/commons-server, the underlying backend engine for Mockoon. Mockoon is an open-source development tool designed to configure, run, and scale local mock APIs. When Mockoon is configured to serve static assets or process dynamic file-serving endpoints, it executes verification routines to restrict file requests to predefined target directories.\n\nThe verification system fails to properly restrict the target filesystem scope. An unauthenticated network adversary can bypass path verification and gain read access to files outside of the configured root directory. The root cause resides in character-level prefix comparison logic that fails to enforce directory-boundary separation.\n\nThis vulnerability primarily impacts developers and automated environments running Mockoon inside local development hosts or shared integration servers. Compromise of the local filesystem can leak sensitive metadata, application code, environment assets, or configuration keys stored in sibling workspace folders.

The path containment vulnerability resides in the validation check defined within packages/commons-server/src/libs/server/server.ts under the helper method getSafeFilePath. This method checks if the requested path remains confined within the static directory boundaries.\n\nPrior to version 9.7.0, the validation relied on the JavaScript String.prototype.startsWith() function to check if the target destination resolved path had the correct folder prefix. This string prefix check did not append directory separators or perform semantic path segment checks before evaluating containment.\n\nBecause of this lack of boundary checking, paths that share character prefixes can pass validation. For instance, if the configured directory path is /srv/public and the resolved file path is /srv/public_backup/secret.json, the validation step evaluates '/srv/public_backup/secret.json'.startsWith('/srv/public') as true. This allows the system to read and return files from sibling directories that begin with the same string prefix, bypassing intended directory boundaries.

Before the patch in version 9.7.0, getSafeFilePath verified both absolute and relative file paths as follows:\n\ntypescript\nif (isPathAbsolute) {\n if (!staticBaseDir || !resolvedPath.startsWith(staticBaseDir)) {\n throw new Error(\n 'Access to absolute path outside of the original static base directory'\n );\n }\n} else {\n if (!resolvedPath.startsWith(this.options.environmentDirectory)) {\n throw new Error(\n 'Access to relative path outside of the environment base directory'\n );\n }\n}\n\n\nThe official remediation in commit b42bdfb7f82e83f0e81bea8e6fe41adf5ec82585 introduced a secure containment evaluation method isPathInsideBase utilizing Node.js's native path.relative function:\n\ntypescript\nconst isPathInsideBase = (basePath: string, candidatePath: string) => {\n const relativePath = relative(basePath, candidatePath);\n return (\n relativePath === '' ||\n (!relativePath.startsWith('..') && !isAbsolute(relativePath))\n );\n};\n\n\nBy resolving the relative distance from basePath to candidatePath, the function checks if the candidate path steps out of the parent structure. If the calculated relative path contains the upward traversal prefix .., the system correctly flags and blocks the request.

Exploiting this path traversal relies on configuring or targeting a Mockoon endpoint with a response type set to FILE where the path uses a dynamic helper, such as {{queryParam 'file'}} or {{urlParam 'file'}}. The presence of dynamic template components allows remote client control over the file lookup string.\n\nAn attacker identifies an active file retrieval route and submits a query string containing traversal operators targeted at sibling folders, such as ?file=../../app_backup/.env. The application resolves the input relative to the mock application directory.\n\nThe resolved absolute location is evaluated against the validation engine. Because the sibling folder name starts with the prefix of the base folder, the prefix validation returns true, allowing the backend file service to open, read, and return the sensitive data to the network client.\n\nmermaid\ngraph LR\n A["Client Input (Traversal Payload)"] --> B["Path Resolution (Node.js)"]\n B --> C["Validate Path in getSafeFilePath()"]\n C --> D{"path.relative Check"}\n D -- "Begins with '..'" --> E["Throw Access Error"]\n D -- "Contained within Base" --> F["Read & Serve File Content"]\n

The potential impact of CVE-2026-59149 is marked as CVSS 6.5 (Medium). The exploit allows unauthorized, unauthenticated reading of data directly from the host filesystem in environments running the Mockoon server backend.\n\nDepending on the system layout, attackers can read private workspace configuration files, source code, database passwords, or operational credentials located in adjacent directories sharing the prefix name. This vulnerability is especially critical if Mockoon is deployed inside continuous integration (CI) environments or shared testing infrastructure.\n\nBecause this vulnerability does not allow modification of file contents or remote code execution directly, the scope is unchanged, and integrity is not directly compromised. However, the exfiltrated sensitive files often facilitate escalation paths in overall system deployment infrastructure.

Remediation requires upgrading the Mockoon client, the command-line engine, or the underlying @mockoon/commons-server package to version 9.7.0 or higher. Version 9.7.0 successfully implements a robust boundary verification engine that rejects sibling folder containment bypasses.\n\nIf upgrading cannot be executed immediately, administrators must implement compensating controls:\n\n1. Audit active Mockoon mock setups and remove any FILE responses configured with dynamic template variable components.\n\n2. Introduce reverse proxies or security filters to strip directory traversal characters (e.g. ../ and corresponding URL encodings) from request paths.\n\n3. Run Mockoon under containerized or highly restricted execution boundaries with standard non-root service accounts, ensuring the host mount volumes do not expose sibling project configurations.