CVE-2026-59148: @Mockoon/commons-server: Unauthenticated admin API + wildcard CORS allows mock-state hijack and secret theft

Mockoon’s admin API (commons-server/src/libs/server/admin-api.ts) is mounted on the same Express listener as the user-defined mock routes, enabled by default in every shipped runtime (commons-server, CLI, serverless), serves Access-Control-Allow-Origin: * on every endpoint with all HTTP methods allowed including PUT/POST/PATCH/DELETE/PURGE and Content-Type in Access-Control-Allow-Headers, and has zero authentication of any kind (no token, no shared secret, no MOCKOON_ADMIN_TOKEN env var — searched the repo, returns zero hits).

Any unauthenticated caller who can reach the mock server’s port (default 0.0.0.0:3000) can:

• Read every MOCKOON_* env var used by the operator as secret material in templates (getEnvVar helper).
• Write arbitrary process env vars (no prefix check on the WRITE path) — poison operator’s MOCKOON_API_KEY, MOCKOON_JWT_SECRET, …, or write process-level vars like AWS_SECRET_ACCESS_KEY that the surrounding runtime consumes.
• Rewrite every mock route’s body / status / headers in-runtime via PUT /mockoon-admin/environment — downstream consumers (frontend dev-server, CI test suite, integration partner) receive attacker-controlled responses and headers including Set-Cookie, Location, Content-Security-Policy, etc.
• Read transaction logs / SSE stream (consumer’s request bodies + auth headers in clear).
• Read/write global template vars; purge state / data buckets / logs.

Because of the wildcard CORS reply, the attack also lands cross-origin from a browser: a developer who runs mockoon-cli start ... locally and visits a malicious website gets their mock state hijacked.