Executive Summary
A second critical flaw, CVE-2026-61568, has been disclosed in @zereight/mcp-gitlab — the popular Model Context Protocol server that connects AI coding agents to GitLab. Versions prior to 2.1.30 expose the server's Streamable HTTP endpoint without an effective Host or Origin allowlist, letting a malicious webpage use DNS rebinding to reach a victim's local MCP listener and drive it as though it were a legitimate client. Combined with the SSRF/token-leak issue disclosed as CVE-2026-61559, researchers at Pluto Security describe the pair as enough to fully hijack a victim's GitLab account from a single visited webpage.
CVSS Score: 9.6 (Critical)
Vulnerability Overview
| Attribute | Value |
|---|---|
| CVE ID | CVE-2026-61568 |
| CVSS Score | 9.6 (Critical) — CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H |
| CWE | CWE-350 — Reliance on Reverse DNS Resolution for a Security-Critical Action |
| Component | @zereight/mcp-gitlab Streamable HTTP transport |
| Attack Vector | Network, requires the victim to visit a malicious page |
| Privileges Required | None |
Affected Versions
| Package | Affected Versions | Fixed Version |
|---|---|---|
@zereight/mcp-gitlab | ≤ 2.1.29 | 2.1.30 |
How the Exploit Works
MCP servers running the Streamable HTTP transport are typically bound to localhost and trusted implicitly because they're assumed to be reachable only by the local AI client. DNS rebinding defeats that assumption:
1. Victim visits an attacker-controlled webpage while an MCP-GitLab instance
listens locally (e.g. 127.0.0.1:PORT)
2. The page's initial DNS lookup resolves to an attacker server, passing any
same-origin checks tied to that hostname
3. The attacker's DNS server then rebinds the same hostname to 127.0.0.1
4. The browser, still treating the origin as "trusted," sends requests that
now land on the local MCP server, carrying an attacker-chosen Host/Origin
5. Because the server accepts those headers without an allowlist, it treats
the browser-originated request as a legitimate MCP client and processes
the MCP initialization handshakeFrom there, the attacker's page can drive the MCP server's GitLab tool calls with the same authority as the victim's actual AI agent — and, chained with CVE-2026-61559's token exfiltration path, walk away with the victim's GitLab credentials entirely.
Impact of Successful Exploitation
| Impact | Description |
|---|---|
| Full GitLab Account Takeover | Chained with CVE-2026-61559, leads to complete token compromise |
| Unauthorized Repository Access | Read/write to private repos the victim's token can reach |
| CI/CD Pipeline Abuse | Trigger or modify pipelines, exfiltrate CI secrets |
| Silent Exploitation | Requires only that the victim visit a page — no explicit consent to any GitLab action |
Remediation
Step 1: Update Immediately
npm install @zereight/mcp-gitlab@latest
npx @zereight/mcp-gitlab --version # confirm >= 2.1.30Version 2.1.30 enforces Host and Origin validation middleware by default, rejecting requests that don't match the expected local origin.
Step 2: Network-Level Hardening
- Bind the MCP server strictly to
127.0.0.1and avoid exposing it on any interface reachable from a browser on an untrusted network. - Where supported, enforce an explicit Host/Origin allowlist rather than relying on default bind behavior alone.
- Treat any locally bound MCP server as a potential DNS-rebinding target — this class of bug is common across MCP implementations, not unique to GitLab's.
Step 3: Rotate Credentials
Given the pairing with CVE-2026-61559's token leakage, rotate GitLab tokens used by any MCP-GitLab instance that was running an affected version, and review GitLab audit logs for unexpected API activity.
References
- Pluto Security — One Request to Own Every Repo: How We Hijacked GitLab Through Its MCP Server
- CVEReports — CVE-2026-61568
- NIST NVD — CVE-2026-61568