CVE-2026-61560: GitLab MCP server (@zereight/mcp-gitlab) lets anyone steal its GitLab token

What it is

With SSE=true, the server exposes all of its MCP tools without any authentication. The upload_markdown tool takes an unsanitized file_path and uploads that file to a GitLab project, so an unauthenticated caller can read /proc/self/environ and get GITLAB_PERSONAL_ACCESS_TOKEN. The advisory says this is the default configuration for Docker deployments.

CVE-2026-61559 (GHSA-2h44-8472-frjj, fixed in 2.1.27): with ENABLE_DYNAMIC_API_URL=true, the server uses the X-GitLab-API-URL request header as the base URL for GitLab API calls without any hostname allowlist and attaches the Private-Token to those requests, so a caller can redirect the token to their own server.

CVE-2026-61568 (GHSA-vmp7-252j-cwp7, fixed in 2.1.30): the Streamable HTTP endpoint has no effective Host or Origin allowlist, so a malicious web page can use DNS rebinding to reach a local MCP listener from the victim's browser.

How to check

1. Affected: @zereight/mcp-gitlab (npm) before 2.1.27 for CVE-2026-61560 and CVE-2026-61559, before 2.1.30 for CVE-2026-61568.
2. Check whether you run it with SSE=true or ENABLE_DYNAMIC_API_URL=true, or expose its HTTP port beyond localhost.

How to fix

1. Upgrade @zereight/mcp-gitlab to 2.1.30 or later, which covers all three issues.
2. If the server was ever reachable from a network in SSE mode, revoke and rotate the GitLab personal access token it used.

npm ls @zereight/mcp-gitlab

Sources

• GitHub advisory GHSA-cv3r-c5h8-f4g5 ↗
• GitHub advisory GHSA-2h44-8472-frjj (CVE-2026-61559) ↗
• GitHub advisory GHSA-vmp7-252j-cwp7 (CVE-2026-61568) ↗
• NVD: CVE-2026-61560 ↗