@zereight/mcp-gitlab EUVD-2026-80008

Exploitation requires the server to be started with SSE transport enabled (SSE=true) - which the advisory states is the default for Docker deployments - because that mode exposes all MCP tools with no authentication and makes the endpoint network-reachable. The attacker must have network access to that SSE HTTP port and calls the upload_markdown tool with a traversal/absolute file_path (e.g. /proc/self/environ). Meaningful value requires the server to have been configured with a GITLAB_PERSONAL_ACCESS_TOKEN (or OAuth/job token) in its environment so that stolen credentials enable account takeover. LIMITING FACTORS: deployments using the stdio transport (SSE not set) do not expose the network tool surface; upgrading to 2.1.27 removes raw local-path reads in remote mode.

This is a genuine high-priority issue, not a high-CVSS-but-low-risk paper cut. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) is corroborated by the description: in SSE transport mode (SSE=true) the MCP server exposes every tool with no authentication, and the description explicitly states this is the DEFAULT for Docker deployments - so the unauthenticated network vector applies to out-of-the-box installs, not an edge configuration. The path-traversal file read (CWE-22) chains directly into credential theft (/proc/self/environ → GITLAB_PERSONAL_ACCESS_TOKEN) and full GitLab account takeover, which supports the C:H/I:H/A:H triad, though note A:H/I:H are downstream consequences of stolen-token abuse rather than a direct availability/integrity impact in the tool itself. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so despite the 9.8 there is no evidence of active exploitation at time of analysis - the risk is high potential rather than confirmed in-the-wild use. Conflicting/limiting signal to verify: exploitation requires SSE=true, so operators running the default stdio transport are not exposed; the '9.8 everywhere' impression should be tempered by that configuration gate even though Docker's default enables it.

An attacker who can reach the MCP server's SSE HTTP port (default Docker deployment, no authentication) invokes the upload_markdown tool with file_path set to /proc/self/environ. The server reads that file and uploads it to a GitLab project, returning contents that include GITLAB_PERSONAL_ACCESS_TOKEN, which the attacker then uses to take over the associated GitLab account. No public exploit code was identified, but the attack is trivially scriptable given AV:N/AC:L/PR:N and the concrete file path named in the advisory.