CVE-2026-59148: Unauthenticated Administrative API and CORS Misconfiguration in Mockoon

Mockoon versions prior to 9.7.0 contain a critical vulnerability where high-privilege administrative endpoints, routed through the /mockoon-admin path, are exposed by default without authentication. These routes are co-located on the same listener port as standard mock routes designed to receive untrusted external traffic. This architecture creates an entry point where any party capable of reaching the mock service can access administrative controls.\n\nThe administration endpoints provide several dangerous actions, such as dynamically editing mock route behaviors, viewing raw transaction logs containing HTTP headers, and writing configuration parameters directly to the running process. Because the application did not perform any access control verification, this design flaw left Mockoon services vulnerable to unauthorized administrative operations. This class of weakness is categorized under CWE-306.\n\nIn addition to the lack of authentication, Mockoon implemented a permissive Cross-Origin Resource Sharing (CORS) configuration that used a wildcard origin header. When local servers are executed during development, browsers allow external web resources to query these services if wildcard headers are active. Consequently, malicious websites could execute cross-origin requests targeting Mockoon's administrative API, creating a remote exploitation vector against local systems.

The primary technical flaw resides within the administrative route registration module in packages/commons-server/src/libs/server/admin-api.ts. In affected versions, the router handles administrative requests without invoking any session, credential, or token-based authorization filters. Because administrative interfaces share the same port and server thread as user-defined routes, any client that can route requests to Mockoon also has access to administrative controls.\n\nFurthermore, the CORS middleware registered for administrative endpoints unconditionally set the Access-Control-Allow-Origin header to *. This configuration tells the web browser to ignore cross-origin isolation policies. If an engineer hosts Mockoon locally and visits a malicious site, scripts on that site can send queries to local admin ports and read the responses directly, bypassing standard local-host isolation boundaries.\n\nAnother critical weakness involves the /mockoon-admin/env-vars route mapping to setEnvVarHandler. The code took parameters from the incoming request body and assigned them directly to Node's process.env dictionary without sanitization or validation. Without structural constraints, attackers could overwrite sensitive variables like NODE_OPTIONS to execute shell commands, enabling arbitrary code execution under the privileges of the active process.

In versions preceding the fix, the CORS configuration on /mockoon-admin* paths configured permissive headers without authentication check steps. The implementation of environment variable writing accepted keys directly into the global environment array.\n\ntypescript\n// VULNERABLE: Wildcard CORS configuration without authorization checks\napp.use(`${adminApiPrefix}*`, (req, res, next) => {\n res.setHeaders(\n new Headers({\n 'Access-Control-Allow-Origin': '*',\n 'Access-Control-Allow-Methods': 'GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS',\n 'Access-Control-Allow-Headers': 'Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With'\n })\n );\n next();\n});\n\n// VULNERABLE: Direct write capability to environment dictionary\nconst setEnvVarHandler = (req, res) => {\n try {\n const { key, value } = req.body;\n if (key !== undefined && value !== undefined) {\n process.env[key] = value;\n res.send({ message: `Environment variable '${key}' has been set` });\n }\n } catch (_error) {\n res.status(400).send({ message: 'Invalid request' });\n }\n};\n\n\nThe fix introduced in commit c420b5a56918475b8663977b51e5f986e45b3299 added mandatory authorization token verification using a cryptographically secure token. It also restricted CORS origins to authorized lists and limited environment variable modifications to keys that begin with an approved prefix.\n\ntypescript\n// PATCHED: Authentication check using constant-time evaluation\nconst hasValidAdminApiToken = (providedToken: string): boolean => {\n const expectedTokenBuffer = Buffer.from(adminApiAuthToken, 'utf8');\n const providedTokenBuffer = Buffer.from(providedToken, 'utf8');\n if (expectedTokenBuffer.length !== providedTokenBuffer.length) {\n return false;\n }\n return timingSafeEqual(expectedTokenBuffer, providedTokenBuffer);\n};\n\n// PATCHED: Prefix restriction on environment variable assignments\nif (!envVarsPrefix) {\n res.status(403).send({\n message: 'Environment variable writes are disabled when the prefix is empty'\n });\n return;\n}\nconst prefixedKey = key.startsWith(envVarsPrefix) ? key : envVarsPrefix + key;\nprocess.env[prefixedKey] = value;\n\n\nThis update resolves the core vulnerabilities by securing the administration interface against unauthorized access and preventing dangerous environment modifications. The use of timingSafeEqual blocks attempts to crack the token via timing side-channels, ensuring the validation logic is robust.

Exploitation of CVE-2026-59148 relies either on direct network access to the port or on a drive-by cross-origin attack targeting local developers. The cross-origin scenario is particularly effective because Mockoon is widely run on local workstations (localhost:3000). If a developer visits a malicious website, client-side scripts running on that site can run silent HTTP requests to the Mockoon port.\n\nmermaid\ngraph LR\n subgraph "Victim Web Browser"\n A["Developer Browser"] -- "1. Navigates to" --> B["Malicious Website"]\n B -- "2. Loads exploit script" --> A\n A -- "3. Executes fetch to localhost" --> C["Local Mockoon Port 3000"]\n end\n subgraph "Local Host"\n C -- "4. Administrative actions executed" --> D["Mockoon Service Process"]\n D -- "5. Responds with wildcard CORS" --> A\n end\n A -- "6. Transmits data to C2" --> E["Attacker Server"]\n\n\nBecause the browser sends local requests, and Mockoon responds with Access-Control-Allow-Origin: *, the browser permits the exploit script to read administrative responses. The script can read transaction logs via /mockoon-admin/logs, extracting active session credentials and API keys.\n\nAn attacker can also inject malicious endpoints by issuing a PUT request to /mockoon-admin/environment. This allows them to dynamically reconfigure the mock server to return phishing content or redirect active client calls to malicious endpoints, compromising other development workflows.

The severity score for this vulnerability is 8.8 (High). The primary impact includes complete control over Mockoon's administrative capabilities, allowing attackers to manipulate mock responses and monitor network traffic. This compromise affects developers relying on these mocks for local application validation.\n\nConfidentiality is severely compromised. Since mock servers log standard transactional headers, authentication headers like Bearer tokens, API keys, and cookies are written directly to transaction files. Attackers can exfiltrate these files through the log endpoint, gaining access to production credentials used by clients during testing.\n\nFurthermore, the ability to write arbitrary environment variables provides a path to system compromise. By overwriting process environment variables, an attacker can manipulate application controls or launch arbitrary processes, leading to remote code execution under the privileges of the system user running the Mockoon server.

The primary remediation strategy is upgrading all Mockoon clients and libraries to version 9.7.0 or higher. This update resolves the vulnerability by introducing mandatory administrative authentication and restricting permissive CORS settings. The patch also prevents arbitrary environment variable overrides by implementing prefix restrictions.\n\nIf upgrading is not immediately possible, disable the administrative API. This can be achieved by running the Mockoon CLI with the --disable-admin-api flag, or setting enableAdminApi: false in serverless configuration options. Disabling this API prevents administrative routes from mounting, eliminating the attack surface.\n\nIn addition, ensure that the mock service is configured to bind strictly to the loopback interface (127.0.0.1 or ::1) instead of 0.0.0.0. This step prevents external systems from reaching the ports over the network. Setting up localized firewall rules further restricts inbound communication to these development environments.