GitLab MCP Server CVE-2026-61568

Requires ALL of: the @zereight/mcp-gitlab server (versions < 2.1.30) running with the Streamable HTTP transport enabled and a valid GitLab token configured; the server reachable at its default loopback bind (127.0.0.1) with no MCP_ALLOWED_HOSTS/MCP_ALLOWED_ORIGINS or effective Host/Origin allowlist (the pre-patch default); and the victim actively browsing to an attacker-controlled web page that performs DNS rebinding (UI:R). Limiting factors: exploitation needs victim user interaction, a locally running listener with a configured token, and - where REMOTE_AUTHORIZATION=true is set - token checks block material unauthenticated GitLab API tool calls, reducing impact to the HTTP-boundary/initialize failure. Not exploitable if the server is unpatched-but-fronted by an external proxy enforcing Host/Origin, or if the token has minimal scope.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H = 9.6) rates this Critical, but several signals temper real-world urgency. Exploitation is network-based and requires no authentication at the HTTP boundary (PR:N), yet it is fundamentally gated on user interaction (UI:R): a victim must have the MCP server running locally with a valid GitLab token AND visit an attacker-controlled web page for the DNS-rebinding attack to fire. A public proof-of-concept exists (referenced in the GHSA advisory), and a vendor patch is available in v2.1.30 - so this is a real, actionable priority for anyone running the affected package, not merely a paper-high score. However, there is NO CISA KEV listing and NO EPSS score provided, so there is no evidence of active or widespread exploitation; treat this as a patchable, POC-backed defensive priority rather than an in-the-wild campaign. The advisory itself notes an important nuance conflicting with the C:H/I:H/A:H rating: when REMOTE_AUTHORIZATION=true, token checks block unauthenticated tools/list and material GitLab API calls - the confirmed defect is the HTTP/Host-Origin boundary failure reaching the MCP initialize path; full C/I/A impact against GitLab data depends on the deployment lacking token enforcement or the attacker chaining to the victim's configured token. The A:H component in particular is the weakest-supported metric. The S:C (scope change) is defensible because the local MCP server acts as a bridge to a separate security authority (the victim's GitLab instance).

A developer runs @zereight/mcp-gitlab locally (default bind 127.0.0.1) with their GitLab token configured, then browses to an attacker-controlled web page. That page uses DNS rebinding to point its hostname at the victim's loopback listener while sending an attacker-controlled Host/Origin; because the server enforces no effective Host/Origin allowlist, the browser request reaches the MCP initialize path and the attacker can drive GitLab tool calls in the victim's context. A public PoC demonstrating the no-token initialize succeeding with attacker-controlled headers is referenced in the GHSA advisory.