CVE-2026-61559: GitLab MCP Server SSRF Vulnerability

CVE-2026-61559 Overview

CVE-2026-61559 is a Server-Side Request Forgery (SSRF) vulnerability in @zereight/mcp-gitlab, a Model Context Protocol (MCP) server that exposes GitLab APIs to AI assistants. Versions from 0.0.1 through 2.1.26 accept the X-GitLab-API-URL HTTP header as the base URL for outbound GitLab API calls when ENABLE_DYNAMIC_API_URL=true. The server validates URL syntax but enforces no hostname allowlist. Attackers who can reach the HTTP transport can redirect API calls to an attacker-controlled host, which receives the victim's Private-Token. Version 2.1.27 introduces a host allowlist that resolves the issue.

Critical Impact
Attackers can steal the victim's GitLab Private-Token by injecting a single HTTP header, granting full access to the victim's GitLab account and repositories.

Affected Products

@zereight/mcp-gitlab versions 0.0.1 through 2.1.26
Deployments with ENABLE_DYNAMIC_API_URL=true
MCP server instances exposing the HTTP transport to untrusted callers

Discovery Timeline

2026-09-15 - CVE-2026-61559 published to NVD
2026-09-17 - Last updated in NVD database

Technical Details for CVE-2026-61559

Vulnerability Analysis

The MCP server bridges AI assistants to the GitLab REST API using a Private-Token supplied by the operator. When ENABLE_DYNAMIC_API_URL=true, callers can override the GitLab base URL per request using the X-GitLab-API-URL header. The server passes the header value to new URL() for syntactic validation only. No hostname allowlist, scheme restriction, or private-address filter is applied.

Outbound fetch calls then attach the operator's Private-Token to any URL derived from the attacker-supplied header. The token is transmitted to the attacker's host in the Authorization or PRIVATE-TOKEN header, enabling full impersonation against the legitimate GitLab instance. This maps to [CWE-918: Server-Side Request Forgery].

Root Cause

The root cause is missing destination validation. The pre-patch code trusted any well-formed URL as a valid GitLab endpoint and forwarded credentials without confirming the target host. Credentials intended for a specific tenant were bound to the request scope, not the destination host.

Attack Vector

Any caller reachable by the HTTP transport, including a low-privileged tenant, an AI agent processing untrusted input, or a network peer, can send a request containing an X-GitLab-API-URL header pointing to an attacker-controlled host. The next outbound GitLab API call issued in that request context is redirected. The attacker's server logs the incoming Private-Token and can immediately reuse it against the real GitLab instance.

typescript

// Patched validation logic in index.ts (v2.1.27)
const allowedApiUrl = GITLAB_ALLOWED_API_URLS_BY_HOST.get(parsed.host);
if (!allowedApiUrl) {
  throw new Error(
    `GitLab API URL host is not allowed: ${parsed.host}. ` +
      "Add the host to GITLAB_ALLOWED_HOSTS or GITLAB_API_URL."
  );
}

return allowedApiUrl;

Source: GitHub Commit 6ffb4cc

Detection Methods for CVE-2026-61559

Indicators of Compromise

Inbound HTTP requests to the MCP server containing an X-GitLab-API-URL header pointing to an unexpected or external host.
Outbound network connections from the MCP server host to domains other than the configured GitLab instance.
GitLab audit log entries showing API calls originating from unfamiliar IP addresses using the operator's Private-Token.

Detection Strategies

Inspect reverse-proxy or load-balancer logs for the X-GitLab-API-URL header and alert on values that do not match the sanctioned GitLab host.
Correlate outbound DNS and TCP flows from the MCP server against an allowlist of expected GitLab endpoints.
Review GitLab personal access token usage for anomalous source IPs, user agents, or unusual API call sequences.

Monitoring Recommendations

Enable egress logging on hosts running @zereight/mcp-gitlab and forward telemetry to a SIEM for baseline deviation analysis.
Rotate GitLab Private-Token values on a defined schedule and monitor GitLab admin audit events for token use from new locations.
Alert on the presence of ENABLE_DYNAMIC_API_URL=true in configuration management systems across vulnerable versions.

How to Mitigate CVE-2026-61559

Immediate Actions Required

Upgrade @zereight/mcp-gitlab to version 2.1.27 or later.
Immediately revoke and rotate any GitLab Private-Token values exposed to a vulnerable server that had ENABLE_DYNAMIC_API_URL=true.
Audit GitLab activity for the affected token to identify unauthorized repository access, code changes, or CI/CD pipeline runs.

Patch Information

Version 2.1.27 introduces a GITLAB_ALLOWED_HOSTS mechanism that enforces a hostname allowlist before honoring X-GitLab-API-URL. Requests targeting unlisted hosts are rejected with an HTTP 400 response. Details are documented in GitHub Release v2.1.27, Pull Request #625, and GHSA-2h44-8472-frjj.

Workarounds

Set ENABLE_DYNAMIC_API_URL=false (or unset it) if per-request base URL selection is not required.
Restrict network access to the MCP HTTP transport so only trusted internal callers can issue requests.
Place the MCP server behind a reverse proxy that strips or validates the X-GitLab-API-URL header before it reaches the application.

bash

# Disable dynamic API URL selection and pin the GitLab host
unset ENABLE_DYNAMIC_API_URL
export GITLAB_API_URL="https://gitlab.example.com/api/v4"
export GITLAB_ALLOWED_HOSTS="gitlab.example.com"