Description

`@zereight/mcp-gitlab` is a Model Context Protocol server for GitLab. Starting in version 0.0.1 and prior to version 2.1.27, when the environment variable `ENABLE_DYNAMIC_API_URL=true` is set, the server reads the `X-GitLab-API-URL` HTTP request header and uses it as the base URL for all outbound GitLab API calls made within that request. The server validates that the value is a well-formed URL (`new URL(dynamicApiUrl)`) but applies no allowlist or hostname restriction. The server then attaches the victim's `Private-Token` to every outbound fetch that uses the redirected URL. Any caller who can reach the HTTP transport can set `X-GitLab-API-URL` to an attacker-controlled host. The next GitLab API call the server makes delivers the victim's token to that host. Version 2.1.27 contains a patch.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-09-15T21:16:41.390Z",
  "pubdate": "2026-09-15T21:16:41.390Z",
  "executiveSummary": "The @zereight/mcp-gitlab Model Context Protocol server is susceptible to an arbitrary server-side request redirection vulnerability. When the ENABLE_DYNAMIC_API_URL environment variable is enabled, the application improperly trusts the user-supplied X-GitLab-API-URL HTTP header to dictate the destination of outbound API requests. This flaw allows an attacker to intercept sensitive authentication credentials, specifically the user's Private-Token, by redirecting outbound traffic to an attacker-controlled endpoint. The vulnerability affects all versions from 0.0.1 prior to 2.1.27. Exploitation requires the victim to interact with an environment where the attacker can influence HTTP headers, potentially leading to unauthorized GitLab account access and data exfiltration. Given that the server performs no allowlist or hostname validation on the header input, the risk of credential theft is critical in multi-tenant or shared-proxy deployment scenarios.",
  "technicalDetails": "The vulnerability resides in the request handling logic of the @zereight/mcp-gitlab server. The root cause is the insecure implementation of dynamic URL routing that relies entirely on client-supplied headers without enforcing a strict allowlist of authorized API endpoints. When ENABLE_DYNAMIC_API_URL=true is set, the server processes the X-GitLab-API-URL header for incoming requests.\nThe server employs a surface-level validation using the JavaScript URL constructor (new URL(dynamicApiUrl)) to verify that the string is a syntactically correct URI; however, this does not validate the host's identity or origin. Consequently, the server blindly constructs outbound API calls to any arbitrary host specified by an attacker. The application's core security failure is the subsequent inclusion of the victim's Private-Token in the headers of these forged outbound requests.\nThe attack flow follows a predictable pattern: 1) An attacker initiates an MCP request and injects the X-GitLab-API-URL header, setting it to a malicious URL under their control. 2) The server, acting as a proxy or client, processes this header and updates its base configuration for the session. 3) Upon the next automated GitLab API call triggered by the MCP server, the internal fetch routine uses the malicious base URL. 4) The server automatically attaches the Private-Token associated with the victim's session to this outbound request. 5) The attacker captures the incoming HTTP request at their malicious host, effectively stealing the victim's sensitive Private-Token.\nThis vulnerability is particularly dangerous because the redirection is performed server-side by the MCP host. Because the server trusts the manipulated header, it facilitates the exfiltration of credentials that are otherwise intended solely for the legitimate GitLab instance. This exposure persists until the server instance is updated or the vulnerable configuration flag is disabled. The vulnerability necessitates no specific authentication bypass techniques, as the server acts as an authorized agent for the user, inadvertently delivering the authenticated token directly to the attacker."
}