Two advisories published this week describe the same mistake in different tools: an MCP server meant for one developer’s machine that answered anyone on the network.
Mendix Studio Pro: update to 11.16.0 or 11.12.7
Siemens’ SSA-710379, published 10 November, covers two flaws in the MCP server inside Mendix Studio Pro, Siemens’ low-code IDE:
- CVE-2026-112136 (CVSS 4.0 score 9.2, CVSS 3.1 8.8): the MCP server’s HTTP listener is not restricted to the loopback interface, so an attacker with network access can talk to it.
- CVE-2026-112137 (CVSS 4.0 5.1): it does not check Content-Type and Origin headers, so a malicious web page can make your browser send requests to the local MCP server (cross-site request forgery).
Affected are Studio Pro 11 from 11.15.0 up to 11.16.0, and 11.12 from 11.12.6 up to 11.12.7. The fix is to update to 11.16.0 or 11.12.7. Until then, Siemens says to block inbound traffic on port 7782, which a standard Windows firewall already does, and to use a browser with Private Network Access protection or an extension that stops websites from calling 127.0.0.1.
fast-agent: the same default, with a shell attached
The fast-agent advisory (CVE-2026-102610, published 9 November) shows how far this can go. fast-agent serve exposed the agent over MCP on 0.0.0.0:8000 with no authentication and no warning. With --shell, the flag in the README quickstart, the agent had a shell tool, and the reporter shows an unauthenticated client asking it to run commands and getting the output back. Without --shell, a stranger could still spend your model credits and use your configured tools. Versions up to 0.7.20 of fast-agent-mcp are affected; the fix is in 0.7.21, released on 19 June, so the advisory documents a hole that up-to-date installs already closed. GitHub rates it medium (6.4) because it needs serve mode.
Why this matters
A local MCP server is a remote-control port for your tools, so the bind address and an auth check are the whole perimeter. Run ss -ltnp (or netstat -ano on Windows) and look for agent or MCP processes listening on 0.0.0.0. The NVIDIA App’s local MCP server was another one that shipped switched on. The fix is the same each time: bind to loopback, check the Origin header, and require a token scoped to that server, as our note on why a token for one MCP server belongs to that server explains.

The Campfire
CommentsThanks. Your comment is waiting for the desk. Once it is approved it appears here within about a minute.
Add a comment