Mockoon's Prototype Pollution Flaw: Your Mock API Is a Real Attack Surface

A team spins up a mock API for a mobile developer, shares a preview URL, and moves on. The responses contain fake orders, so nobody treats the service like production. But the process behind that URL still parses requests, loads dependencies, and runs with whatever network access its container was given. Fake business data does not make those capabilities harmless.

What Mockoon disclosed

On September 16, 2026, Mockoon published GHSA-cmwm-hp2w-h3cx, a critical prototype pollution issue in its multipart form parser. The advisory lists @mockoon/commons-server versions through 9.8.0 as affected and 9.9.0 as patched. An unauthenticated request could modify shared JavaScript object state, including through a nonexistent route because parsing happened before route matching. Read Mockoon's advisory.

The demonstrated effects include process-wide integrity damage and errors or crashes affecting later requests. The report discusses further escalation as a possibility, but does not demonstrate remote code execution. That distinction matters when deciding what evidence to collect and how to communicate the risk.

The exposure problem starts before the payload

For a typical team, the first useful question is which mock services are reachable from outside the organization. An API that exists only for local development should not inherit the public routing of a customer application. A shared test environment needs an owner, an expiry date, and a deliberate access policy.

Review what these services can reach as well. A disposable mock server with a production database password or a broad cloud service account is no longer disposable. Use synthetic fixtures and narrowly scoped credentials, and keep its network permissions separate from the systems it imitates.

A practical cleanup plan

1. Inventory Mockoon CLI deployments, containers, and applications embedding its server package. Check the installed dependency, not just the desktop app version.
2. Upgrade affected deployments to a release containing commons-server 9.9.0 or later, then rebuild and restart them.
3. Remove public routes that are unnecessary. Put shared previews behind access controls and confirm that alternate hostnames and ports follow the same policy.
4. Review mounted secrets and outbound network access. Record an owner and a removal date for each preview so it does not become a permanent forgotten service.

Where a BlackSight scan helps

BlackSight's DNS reconnaissance and port scans can surface discoverable subdomains and reachable services on the assets you include. That gives an operator a concrete way to notice an unexpectedly public mock endpoint and remove its exposure. Add the endpoint itself as a target; scanning only your main marketing site will leave a separate preview service outside that scan's scope.

Use the API scanner to examine the responses it can reach and the technology scan to collect identifiable software information. Package matching depends on the evidence exposed by the service. A black-box scan cannot reliably read a hidden server dependency version or guarantee detection of this particular parser bug; check the deployed package inventory and apply the vendor fix.

After restricting access, repeat the external checks and retain the results with the change record. The useful outcome is a patched service whose public reachability matches its intended audience. Our API security checklist is a good starting point for giving temporary APIs the same review discipline as permanent ones.