Unauthenticated arbitrary file read in @zereight/mcp-gitlab enables GitLab PAT theft and full account takeover (CVE-2026-61560)

A newly published GitHub Security Advisory (GHSA-cv3r-c5h8-f4g5, CVE-2026-61560, CVSS 9.8) describes a critical vulnerability chain in the @zereight/mcp-gitlab npm package, an MCP server that lets AI tooling interact with GitLab.

What was reported

Per the advisory, two issues chain together. First, when the server runs in SSE transport mode (SSE=true) — the default for the project's Docker deployment — the /sse and /messages endpoints have no authentication middleware, so any network-reachable client can invoke all exposed MCP tools using the server's configured GitLab Personal Access Token (PAT). Second, the upload_markdown tool (enabled by default, part of the users toolset) reads a file path directly from user input via fs.readFileSync with no validation, sanitization, or allowlisting, and uploads the file's contents to a GitLab project. The advisory's proof-of-concept chains these to read /proc/self/environ, which contains the server's GITLAB_PERSONAL_ACCESS_TOKEN in plaintext, then retrieves it from the uploaded GitLab attachment. The advisory notes the container runs as root with no USER directive and the default Docker Compose config binds the port to 0.0.0.0, so any deployment following the documented defaults is exposed. Exploit status is listed as PoC-public.

Why it matters for defenders

This is unauthenticated, unauthenticated-network-reachable full account takeover of whatever GitLab identity the MCP server's PAT represents — no credentials or user interaction required. Per the advisory, that can mean access to all repositories, CI/CD secrets and variables, deploy keys, project settings, and admin functions if the token owner has elevated privileges. Given the growing deployment of MCP servers as always-on integration points for AI agents, and that the vulnerable configuration matches the project's own documented Docker defaults, exposure risk is plausibly widespread among teams who stood this up quickly for agent tooling. Other root-readable files called out in the advisory (/etc/shadow, application source, OAuth token files) extend the blast radius beyond the GitLab PAT alone.

What defenders should watch for or do now

• Inventory any running instances of @zereight/mcp-gitlab, particularly Docker deployments using SSE=true, and check whether port 3002 (or whatever it's mapped to) is reachable from outside the intended trust boundary.
• Until a patched release is available and applied, restrict network access to the SSE/messages endpoints (firewall, bind to localhost, or place behind an authenticating reverse proxy) and avoid running the container as root.
• Treat any GitLab PAT that has been used with an exposed instance as potentially compromised — rotate it and review the token's recent API activity/audit log for anomalous access, unexpected upload activity, or unfamiliar IPs.
• At the network/host level, watch for unsolicited HTTP requests to MCP SSE/messages endpoints and for process-level file reads of /proc/self/environ or similar sensitive paths originating from MCP server processes.
• More broadly, audit other self-hosted MCP servers for the same pattern: unauthenticated transport modes combined with tools that accept unsanitized filesystem paths.

This is developing intel based solely on the vendor's own advisory, published today. No confirmed in-the-wild exploitation or ransomware use has been reported at this time. Details, remediation guidance, and any patch status should be confirmed directly from the source: GHSA-cv3r-c5h8-f4g5.