Four Critical MCP Servers and Gateways Ship With No Authentication on the Network Transport (CVE-2026-90898, CVE-2026-59971, CVE-2026-53710, CVE-2026-61560)

Bifrost LLM gateway, MySQL MCP Server, IBM MCP Context Forge, and `@zereight/mcp-gitlab`

Four critical advisories published September 14-15, 2026 share one pattern: the network-facing transport exposed every tool to anyone who could reach it. Bifrost, with authentication off by default, started any stdio MCP client program the moment it was registered, so one unauthenticated `POST /api/mcp/client` ran code as the gateway process user (CVE-2026-90898, CVSS 9.8; fixed in transports v2.1.0). MySQL MCP Server before 0.4.2, with `MCP_TRANSPORT=sse`, bound to `0.0.0.0` with no authentication or DNS-rebinding protection, letting a network attacker or a malicious web page reach `execute_sql` directly (CVE-2026-59971, CVSS 10.0). MCP Context Forge's Python sandbox server before 1.0.2 exposed raw `getattr`, so runtime-built dunder names reached `subprocess.Popen` through the `execute_code` tool (CVE-2026-53710, CVSS 10.0). `@zereight/mcp-gitlab` before 2.1.27 exposed all tools without authentication in SSE mode, the Docker default, and its `upload_markdown` tool read arbitrary files, so `/proc/self/environ` yielded the GitLab personal access token for full account takeover (CVE-2026-61560, CVSS 9.8)

MCP servers written for a trusted local stdio client were given HTTP and SSE transports without adding authentication, turning every tool into an unauthenticated network API