CVE-2026-61568

The @zereight/mcp-gitlab MCP server (version 2.1.18, npm) registers its Streamable HTTP transport at /mcp without any Host or Origin allowlist and without the MCP SDK's DNS-rebinding protections (enableDnsRebindingProtection, allowedHosts, allowedOrigins are never set; express.() is installed globally before any origin check). Because the server binds to 127.0.0.1 by default, a malicious web page can use DNS rebinding to make a victim's browser send cross-origin requests to the local MCP listener with attacker-controlled Host and Origin headers, which the server accepts and processes through the MCP initialize path instead of rejecting at the HTTP boundary. In default local mode this lets the attacker's page drive the MCP session and invoke GitLab tools from the victim's machine; in REMOTE_AUTHORIZATION=true mode, unauthenticated tools/list and GitLab API calls are blocked by token checks, but the browser-boundary flaw remains and a captured/planted Private-Token flow still allows tool listing and calls such as list_project_variables against the victim's GitLab. Affected users are anyone running this package with the Streamable HTTP transport (documented for remote deployments), while stdio users are not directly exposed. The issue is rated CVSS 3.1 9.6 (critical); no public PoC or in-the-wild exploitation is known.

What to do: Upgrade @zereight/mcp-gitlab to a release later than 2.1.18 once a fix ships (verify that StreamableHTTPServerTransport sets enableDnsRebindingProtection with allowedHosts/allowedOrigins, or that a Host/Origin-checking middleware runs before express.() and /mcp). Until then, prefer stdio over Streamable HTTP, do not expose the HTTP listener beyond loopback without a reverse proxy that strictly validates Host and Origin, and set REMOTE_AUTHORIZATION=true so tool calls require a GitLab token. Review server logs and metrics (totalSessions/activeSessions) for unexpected initialize requests or sessions originating from browsers.