What happened
The GitLab MCP server trusts an attacker-controllable HTTP header to redirect outbound API calls (leaking the caller's GitLab Private-Token to any host of the attacker's choosing) and separately lacks Host/Origin validation on its Streamable HTTP transport, enabling DNS-rebinding attacks from a malicious web page against a locally running instance.
Why it matters
GitLab access tokens obtained this way grant an attacker full GitLab API access at the victim's permission level — source code, CI/CD secrets, and repository control — making this a credential-theft primitive against any organization using this widely deployed community MCP connector to let agents interact with GitLab.
Attack vector
When ENABLE_DYNAMIC_API_URL=true, the server reads the caller-controlled X-GitLab-API-URL header and uses it as the base URL for outbound GitLab API calls, validating only that it is a syntactically valid URL with no host allowlist — and attaches the victim's Private-Token to requests sent to that attacker-controlled host, directly leaking the GitLab token. Separately, the Streamable HTTP MCP endpoint lacks an effective Host/Origin allowlist, letting a malicious web page reach a victim's local MCP listener via DNS rebinding while preserving apparent same-origin trust.
Affected systems
@zereight/mcp-gitlab, versions 0.0.1 through 2.1.26 (CVE-2026-61559, fixed 2.1.27); versions prior to 2.1.30 (CVE-2026-61568, DNS rebinding, fixed 2.1.30)
Mitigation
Upgrade to @zereight/mcp-gitlab 2.1.30 or later, which fixes both the header-based SSRF and the DNS-rebinding gap. Disable ENABLE_DYNAMIC_API_URL unless strictly required, and restrict Host/Origin at a reverse proxy in front of any HTTP-mode MCP GitLab server.