Attack Chain

1. An attacker identifies a target running a vulnerable instance of @zereight/mcp-gitlab on a local or accessible network.
2. The attacker exploits missing DNS rebinding protections (F3) by hosting a malicious website that performs a DNS rebind to access the local MCP service.
3. The attacker bypasses authentication (F2) due to the flawed authentication gate logic, allowing interaction with the MCP service without valid credentials.
4. The attacker sends a crafted GraphQL request through the execute_graphql tool.
5. The attacker prepends a comma to the GraphQL document (e.g., ,mutation{...}) to bypass the flawed graphqlQueryContainsWriteOperation check (F1).
6. The service executes the mutation against the connected GitLab instance, ignoring intended read-only and project-scope restrictions.
7. The attacker repeats unauthorized initialize requests with garbage tokens to exhaust session slots, resulting in a DoS (F4).

Impact

Successful exploitation allows for arbitrary unauthorized write operations on GitLab projects, potentially leading to data manipulation or destruction. By leveraging the server's live session, an attacker can access sensitive information, perform repository changes, or interact with CI/CD pipelines outside the intended scope. The unauthenticated DoS vulnerability enables service disruption with minimal request volume, effectively disabling the LLM agent integration.

Recommendation

Prioritized actions for security teams:

• Immediately upgrade @zereight/mcp-gitlab to version 2.1.30 or later to patch the identified safety control bypasses and DoS conditions.
• Implement network-level access controls to restrict access to the MCP server to authorized users or service identities, mitigating the risks posed by the unauthenticated transport and DNS rebinding vulnerabilities (F2/F3).
• Review and harden GitLab project-level permissions to ensure that the token used by the MCP server follows the principle of least privilege, limiting the blast radius of any successful GraphQL injection (F1).
• Configure the MCP service to use a strictly defined SSE_AUTH_TOKEN and disable remote access unless explicitly required and secured by robust reverse-proxy authentication (F3).

As a result, an attacker can supply an arbitrary URL via this header. The server subsequently uses this URL for downstream GitLab API calls, attaching the victim's Private-Token header to the request before sending it to the attacker-controlled server. This flaw allows attackers to steal credentials and gain full authenticated access to the victim's GitLab account, including CI/CD variables, source code, and project management data. The vulnerability is reachable in multi-user deployment scenarios where REMOTE_AUTHORIZATION=true is enabled.

Attack Chain

1. The target is running mcp-gitlab with ENABLE_DYNAMIC_API_URL=true and REMOTE_AUTHORIZATION=true.
2. The attacker initializes a listener on an external server capable of capturing HTTP headers.
3. The attacker crafts a malicious request to the MCP server's tool execution endpoint.
4. The attacker injects the X-GitLab-API-URL header pointing to their listener URL.
5. The MCP server process parses the malicious header and updates the API base URL for the current session.
6. The server initiates a legitimate GitLab API call (e.g., to list issues) using the attacker-supplied URL.
7. The server attaches the victim's Private-Token to the request, facilitating the SSRF-based exfiltration.
8. The attacker receives the victim's token via their listener and proceeds to exfiltrate or manipulate GitLab resources.

Impact

Successful exploitation results in full account compromise at the victim's permission level. Attackers can gain unauthorized access to all repositories, issues, and merge requests, as well as read and modify CI/CD pipelines, secrets, and environment variables. This represents a complete breach of the GitLab security domain for the affected user.

Recommendation

1. If using mcp-gitlab in a multi-user environment, disable ENABLE_DYNAMIC_API_URL immediately until a patched version is available.
2. Implement an allowlist for the X-GitLab-API-URL header by verifying the hostname against a hardcoded list of trusted GitLab instances before the request is processed.
3. Search web access logs for any incoming requests containing the X-GitLab-API-URL header to identify potential exploitation attempts.
4. Rotate all GitLab Personal Access Tokens and CI/CD job tokens for users who interacted with an affected instance of the MCP server.