CVE-2026-61560 in gitlab-mcp
Summary
by MITRE • 09/15/2026
`@zereight/mcp-gitlab` is a Model Context Protocol server for GitLab. Prior to version 2.1.27, the SSE transport mode (`SSE=true`) exposes all MCP tools without any authentication. The `upload_markdown` tool reads arbitrary files from the server's local filesystem via an unsanitized `file_path` parameter and uploads them to a GitLab project. Combined, any unauthenticated network-reachable attacker can read `/proc/self/environ` to steal the server's `GITLAB_PERSONAL_ACCESS_TOKEN` and achieve full GitLab account takeover. This is the default configuration for Docker deployments. Version 2.1.27 contains a patch.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified in @zereight/mcp-gitlab prior to version 2.1.27 represents a critical failure in access control and input validation within the Model Context Protocol server implementation. The core issue stems from the configuration of the Server-Sent Events transport mode, which is enabled by setting SSE=true. In this specific operational state, the application fails to enforce any form of authentication or authorization checks on incoming requests directed at MCP tools. This design flaw effectively exposes all available functionality to any network-reachable actor without requiring valid credentials, creating a direct path for unauthorized interaction with the underlying system services managed by the server.
The technical severity is compounded by the behavior of the upload_markdown tool, which contains an arbitrary file read vulnerability due to unsanitized input handling. When invoked, this tool accepts a file_path parameter that is not properly validated or restricted against directory traversal sequences or absolute path constraints. This allows an attacker to specify paths outside the intended scope, such as /proc/self/environ on Linux-based systems. By reading this specific pseudo-file, which contains the environment variables of the running process, the attacker can extract sensitive configuration data stored in memory, most critically the GITLAB_PERSONAL_ACCESS_TOKEN used by the server to authenticate with GitLab APIs.
The operational impact of combining these two flaws is catastrophic for organizations relying on this service. An unauthenticated attacker who has network access to the SSE endpoint can first retrieve the administrator or user-specific personal access token from the environment variables. With this stolen credential, the attacker gains full authentication capabilities within the associated GitLab instance. This leads to a complete account takeover, allowing the adversary to read private repositories, modify source code, inject malicious commits, delete projects, and potentially escalate privileges further depending on the scope of the compromised token. Given that Docker deployments often default to this configuration, many instances are exposed by default without explicit security hardening steps taken by administrators.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-94 Command Injection via Uncontrolled Search Path Elements or Arbitrary File Read depending on interpretation of the file access mechanism, specifically falling under CWE-530 Exposure of Sensitive Information to an Unauthorized Actor when considering the leakage of environment variables. In terms of MITRE ATT&CK framework tactics, this exploitation path maps directly to Initial Access through Exploitation of Remote Services and Credential Access via Unsecured Credentials or Proc File Discovery for gathering environmental context. The attack chain demonstrates a classic privilege escalation scenario where lack of authentication leads to information disclosure which subsequently enables full system compromise.
Mitigation requires immediate upgrading to version 2.1.27 or later, as this release contains the necessary patches to address these flaws. For environments that cannot immediately upgrade, administrators should disable SSE transport mode if it is not strictly required for their workflow and ensure that any exposed endpoints are protected by a reverse proxy with strict authentication policies such as OAuth2 or API key validation. Additionally, running the service under a restricted user account with minimal file system permissions can limit the impact of arbitrary file read vulnerabilities, although this does not replace the need for proper access control implementation within the application logic itself.