Four Advisories, Zero Patches: Mcp Gitlab's Bad Week

One MCP server. Four disclosures. Three of them critical. If you're running Mcp Gitlab in its default Docker configuration right now, your GitLab personal access token is one HTTP request away from a stranger's inbox.

This is not a "patch when convenient" situation. This is a "check your deployment today" situation.

The chain: unauthenticated access to full account takeover

CVE-2026-61560 is the one that should worry you most. In the default Docker deployment, SSE=true exposes every MCP tool with zero authentication. Anyone who can reach the port can call upload_markdown, which reads arbitrary files from the local filesystem via an unsanitized file_path parameter and pushes them to a GitLab project.

Point that at /proc/self/environ and you've exfiltrated the server's GITLAB_PERSONAL_ACCESS_TOKEN. From there it's full account takeover — no login, no session, no interaction from a victim required.

SSRF via a header nobody should trust

CVE-2026-61559 (CVSS 8.5) lives in a different flag: ENABLE_DYNAMIC_API_URL=true. When set, the server takes the X-GitLab-API-URL request header at face value and uses it as the base URL for API calls. An attacker who controls that header can redirect the server's authenticated requests — and the credentials riding along with them — wherever they want.

DNS rebinding reaches the "local" listener

CVE-2026-61568 shows why "it only listens on localhost" isn't a security boundary. The Streamable HTTP transport doesn't enforce an effective Host/Origin allowlist, so a malicious web page can use DNS rebinding to make a victim's browser talk to their own local MCP listener while spoofing an attacker-controlled Host and Origin. The server accepts it and proceeds straight into MCP initialization — this is CWE-350, trusting reverse DNS for a security decision.

The safety controls were never real controls

GHSA-5648-rgj9-v224 is the audit that ties it together. A source review of commit 60adcc0 (package v2.1.28) found five distinct ways to defeat the server's advertised safety net — read-only mode, the project allow-list, and transport auth all get bypassed, including via execute_graphql, plus a session-exhaustion DoS path. Under the MCP threat model, where tool-call arguments can be shaped by prompt injection or a malicious client, controls that can be talked around aren't controls.

• Don't run SSE mode exposed to any network you don't fully trust. That's the default Docker posture and it's the whole attack surface for CVE-2026-61560.
• Turn off ENABLE_DYNAMIC_API_URL unless you have a specific reason it's on — and even then, treat it as untrusted.
• Don't rely on "localhost" as a security boundary for the Streamable HTTP transport; DNS rebinding doesn't care what your bind address is.
• Rotate your GITLAB_PERSONAL_ACCESS_TOKEN if this server has ever been reachable from an untrusted network.
• Watch Mcp Gitlab's repository for a patched release — none of the four advisories list one yet.

No fix exists for any of these today. Until one ships, the only safe move is to shrink this server's exposure to nothing.