CVE-2026-44895: @yoda.digital/gitlab mcp server @yoda.digital/gitlab-mcp-server's SSE Transport Has No Vulnerability

HIGH
Advisory Identifier: GHSA-8jr5-6gvj-rfpf
CWE-942 CWE-306
Published
Advisory Summary

CVE-2026-44895 is a HIGH @yoda.digital/gitlab-mcp-server's sse transport has no vulnerability (CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains) affecting @yoda.digital/gitlab mcp server libraries in the npm ecosystem. The issue involves @yoda.digital/gitlab-mcp-server's sse transport has no authentication and wildcard cors, exposing all 86 gitlab tools. Remediation is available by upgrading affected packages to version 0.6.0.

CVE-2026-44895 at a Glance

CVE Identifier CVE-2026-44895
GHSA Identifier GHSA-8jr5-6gvj-rfpf
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains
Affected Product @yoda.digital/gitlab mcp server
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-44895

To remediate this vulnerability, upgrade all affected @yoda.digital/gitlab mcp server dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

@yoda.digital/gitlab-mcp-server fixed: 0.6.0
npm install @yoda.digital/gitlab-mcp-server@0.6.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls @yoda.digital/gitlab-mcp-server

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-44895, inspect your project dependencies using npm:

npm ls @yoda.digital/gitlab-mcp-server

Analyze the terminal output to locate any version of @yoda.digital/gitlab mcp server in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.6.0), your application is affected.

Note: The npm ls @yoda.digital/gitlab-mcp-server command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains, where the product uses a web-client protection mechanism such as a content security policy (csp) or cross-domain policy file, but the policy includes untrusted domains with which the web client is allowed to communicate. In @yoda.digital/gitlab mcp server, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## SSE Transport Has No Authentication and Wildcard CORS, Exposing All 86 GitLab Tools Including Destructive Operations A review of `mcp-gitlab-server` at commit `80a7b4cf3fba6b55389c0ef491a48190f7c8996a` uncovered that the SSE HTTP transport — advertised in the README and comparison table as a differentiating feature — runs with no authentication and wildcard CORS on every endpoint. The maintainers' own roadmap confirms auth is a known gap. When `USE_SSE=true`, the HTTP server in `src/transport.ts` sets: ```typescript res.setHeader('Access-Control-Allow-Origin', '*'); res.setHeader('Access-Control-Allow-Methods', 'GET, POST'); res.setHeader('Access-Control-Allow-Headers', 'Content-Type'); ``` The `httpServer.listen(port)` call at line 97 passes no host argument — Node.js defaults to `0.0.0.0`, binding on all interfaces. Two endpoints are exposed with no credential check: - `GET /sse` — opens an SSE connection, returns a session endpoint URL - `POST /messages?sessionId=<id>` — sends MCP messages to the server using the loaded `GITLAB_PERSONAL_ACCESS_TOKEN` Any caller who can reach the port — LAN, cloud instance, or via the browser-tab vector the wildcard CORS enables — gets full access to all 86 tools the server exposes using the operator's GitLab PAT. That includes `delete_repository`, `delete_group`, `push_files`, `create_merge_request`, `update_repository_settings`, and any other tool the server exposes. The PAT doesn't leave the process, but every API call it backs is available to the unauthenticated caller. The wildcard CORS makes the browser-tab vector direct: any web page the operator visits while the server is running can open an SSE connection and make tool calls via cross-origin fetch. No user interaction beyond visiting the page. **PoC — reproduces from the documented USE_SSE=true configuration:** ```bash # Step 1: connect SSE and capture the session endpoint curl -N http://localhost:3000/sse & # Output includes: event: endpoint # data: /messages?sessionId=<UUID> # Step 2: call any tool — no auth header needed curl -X POST "http://localhost:3000/messages?sessionId=<UUID>" \ -H "Content-Type: application/json" \ -d '{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_repository", "arguments": {"project_id": "target-org/private-repo"} } }' # Returns repository data using the operator's GitLab PAT # Same path works for delete_repository, push_files, etc. ``` ## Root cause The HTTP transport in `src/transport.ts` ships with no authentication layer at all and a wildcard `Access-Control-Allow-Origin: *` on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator's `GITLAB_PERSONAL_ACCESS_TOKEN` without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The `httpServer.listen(port)` call at line 97 also passes no host argument, so the bind defaults to `0.0.0.0` and exposes the auth-less surface on every interface. Auth isn't fail-opening on a missing config — there is no auth check at any code path on either `/sse` or `/messages?sessionId=...`. ## Auth boundary violated Trust-domain boundary — untrusted cross-origin browser context (and any unauthenticated network caller) crossing into the trusted server-state-mutating GitLab API surface that the operator's PAT backs. Respected-here: nothing. The transport carries no `Authorization` check, no origin allowlist, no session-binding to the originating client, and no host restriction. Ignored-there: the SSE handler at `src/transport.ts` accepts an arbitrary `Origin` (since `Access-Control-Allow-Origin: *`), opens a session, and the matching `POST /messages?sessionId=...` proxies tool calls — including `delete_repository`, `push_files`, `update_repository_settings` — to the GitLab API using the operator's PAT. Any web page the operator visits while the server runs can drive the full 86-tool surface via cross-origin fetch. The roadmap in `README.md` at line 190 includes `- [ ] SAML/OAuth3 authentication` — confirming the maintainers are already tracking this gap. The issue is disclosure of impact in the interim: operators who follow the README's SSE setup instructions and don't see an auth requirement in the docs may reasonably assume the transport is safe to use on a network-accessible host. **CVSS 4.0:** `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N` — **~6.3 (Medium)**. `AT:P` reflects the `USE_SSE=true` precondition. When that precondition is met, the effective severity for those deployments is High — full GitLab PAT access without authentication. The Medium CVSS is the aggregate across all deployments; for any operator who has activated SSE mode (which the README promotes as a feature), the finding is functionally High. **Fix — four concrete changes:** 1. Require `MCP_GITLAB_AUTH_TOKEN` as a startup precondition when `USE_SSE=true`. If the env var is unset, the server should exit with a clear message before the HTTP server starts: ```typescript if (process.env.USE_SSE === 'true') { if (!process.env.MCP_GITLAB_AUTH_TOKEN) { console.error( 'ERROR: MCP_GITLAB_AUTH_TOKEN must be set when USE_SSE=true. ' + 'SSE transport without authentication exposes all GitLab tools to unauthenticated callers.' ); process.exit(1); } } ``` The token check in `src/transport.ts` validates it on every request: ```typescript const authToken = process.env.MCP_GITLAB_AUTH_TOKEN; if (authToken) { const provided = req.headers['authorization']?.replace(/^Bearer /, ''); if (provided !== authToken) { res.writeHead(401); res.end(JSON.stringify({ error: 'Unauthorized' })); return; } } ``` 2. Bind to `127.0.0.1` by default for the SSE transport rather than `0.0.0.0`. An explicit `MCP_GITLAB_HOST=0.0.0.0` flag with a startup banner warning can expose it to the network for operators who need that — but the safe default should be loopback-only. 3. Replace the wildcard `Access-Control-Allow-Origin: *` with a localhost-only default. When network exposure is intentional (explicit flag + auth token set), an explicit `CORS_ORIGINS` allowlist should be required. 4. The SAML/OAuth3 roadmap item is the right long-term direction. In the interim — before that ships — the three changes above are entirely in the existing codebase with no new dependencies. --- No prior security advisories, CVEs, or public security issues exist for this package — a search of the repository issue list and npm advisory database did not yield any duplicate issues.

CVE-2026-44895 Affected @yoda.digital/gitlab mcp server Versions

1 component(s)
Fixed Versions:
0.6.0
Product / Package Ecosystem Affected Versions Fixed Version
@yoda.digital/gitlab-mcp-server
npm
< 0.6.0
0.6.0

References

Frequently Asked Questions

What is CVE-2026-44895?
CVE-2026-44895 is a security vulnerability in @yoda.digital/gitlab mcp server involving @yoda.digital/gitlab-mcp-server's SSE transport has no authentication and wildcard CORS, exposing all 86 GitLab tools under CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains.
Which @yoda.digital/gitlab mcp server versions are affected?
Affected versions include releases prior to 0.6.0 across affected packages: @yoda.digital/gitlab-mcp-server.
What version fixes CVE-2026-44895?
Upgrading to 0.6.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is @yoda.digital/gitlab-mcp-server affected?
Yes, @yoda.digital/gitlab-mcp-server is affected in releases prior to 0.6.0. Upgrade your dependency to 0.6.0 or later.
What CWE is associated with CVE-2026-44895?
CVE-2026-44895 is classified under CWE-942: Permissive Cross-domain Security Policy with Untrusted Domains (The product uses a web-client protection mechanism such as a Content Security Policy (CSP) or cross-domain policy file, but the policy includes untrusted domains with which the web client is allowed to communicate.).
How can I check npm dependencies for CVE-2026-44895?
Run the dependency tree command: 'npm ls @yoda.digital/gitlab-mcp-server'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-8jr5-6gvj-rfpf",
  "modified" : "2026-06-08T23:34:55Z",
  "published" : "2026-05-09T00:10:28Z",
  "aliases" : [ "CVE-2026-44895" ],
  "summary" : "@yoda.digital/gitlab-mcp-server's SSE transport has no authentication and wildcard CORS, exposing all 86 GitLab tools",
  "details" : "## SSE Transport Has No Authentication and Wildcard CORS, Exposing All 86 GitLab Tools Including Destructive Operations\n\nA review of `mcp-gitlab-server` at commit `80a7b4cf3fba6b55389c0ef491a48190f7c8996a` uncovered that the SSE HTTP transport — advertised in the README and comparison table as a differentiating feature — runs with no authentication and wildcard CORS on every endpoint. The maintainers' own roadmap confirms auth is a known gap.\n\nWhen `USE_SSE=true`, the HTTP server in `src/transport.ts` sets:\n\n```typescript\nres.setHeader('Access-Control-Allow-Origin', '*');\nres.setHeader('Access-Control-Allow-Methods', 'GET, POST');\nres.setHeader('Access-Control-Allow-Headers', 'Content-Type');\n```\n\nThe `httpServer.listen(port)` call at line 97 passes no host argument — Node.js defaults to `0.0.0.0`, binding on all interfaces. Two endpoints are exposed with no credential check:\n\n- `GET /sse` — opens an SSE connection, returns a session endpoint URL\n- `POST /messages?sessionId=<id>` — sends MCP messages to the server using the loaded `GITLAB_PERSONAL_ACCESS_TOKEN`\n\nAny caller who can reach the port — LAN, cloud instance, or via the browser-tab vector the wildcard CORS enables — gets full access to all 86 tools the server exposes using the operator's GitLab PAT. That includes `delete_repository`, `delete_group`, `push_files`, `create_merge_request`, `update_repository_settings`, and any other tool the server exposes. The PAT doesn't leave the process, but every API call it backs is available to the unauthenticated caller.\n\nThe wildcard CORS makes the browser-tab vector direct: any web page the operator visits while the server is running can open an SSE connection and make tool calls via cross-origin fetch. No user interaction beyond visiting the page.\n\n**PoC — reproduces from the documented USE_SSE=true configuration:**\n\n```bash\n# Step 1: connect SSE and capture the session endpoint\ncurl -N http://localhost:3000/sse &\n# Output includes: event: endpoint\n#                  data: /messages?sessionId=<UUID>\n\n# Step 2: call any tool — no auth header needed\ncurl -X POST \"http://localhost:3000/messages?sessionId=<UUID>\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"jsonrpc\": \"2.0\",\n    \"id\": 1,\n    \"method\": \"tools/call\",\n    \"params\": {\n      \"name\": \"get_repository\",\n      \"arguments\": {\"project_id\": \"target-org/private-repo\"}\n    }\n  }'\n# Returns repository data using the operator's GitLab PAT\n\n# Same path works for delete_repository, push_files, etc.\n```\n\n## Root cause\n\nThe HTTP transport in `src/transport.ts` ships with no authentication layer at all and a wildcard `Access-Control-Allow-Origin: *` on every response. The structural defect is that the SSE server stands up a stateful, mutation-capable RPC endpoint that is backed by the operator's `GITLAB_PERSONAL_ACCESS_TOKEN` without any inbound credential check, then advertises itself to every cross-origin browser context via the wildcard CORS header. The `httpServer.listen(port)` call at line 97 also passes no host argument, so the bind defaults to `0.0.0.0` and exposes the auth-less surface on every interface. Auth isn't fail-opening on a missing config — there is no auth check at any code path on either `/sse` or `/messages?sessionId=...`.\n\n## Auth boundary violated\n\nTrust-domain boundary — untrusted cross-origin browser context (and any unauthenticated network caller) crossing into the trusted server-state-mutating GitLab API surface that the operator's PAT backs. Respected-here: nothing. The transport carries no `Authorization` check, no origin allowlist, no session-binding to the originating client, and no host restriction. Ignored-there: the SSE handler at `src/transport.ts` accepts an arbitrary `Origin` (since `Access-Control-Allow-Origin: *`), opens a session, and the matching `POST /messages?sessionId=...` proxies tool calls — including `delete_repository`, `push_files`, `update_repository_settings` — to the GitLab API using the operator's PAT. Any web page the operator visits while the server runs can drive the full 86-tool surface via cross-origin fetch.\n\nThe roadmap in `README.md` at line 190 includes `- [ ] SAML/OAuth3 authentication` — confirming the maintainers are already tracking this gap. The issue is disclosure of impact in the interim: operators who follow the README's SSE setup instructions and don't see an auth requirement in the docs may reasonably assume the transport is safe to use on a network-accessible host.\n\n**CVSS 4.0:** `CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N` — **~6.3 (Medium)**. `AT:P` reflects the `USE_SSE=true` precondition. When that precondition is met, the effective severity for those deployments is High — full GitLab PAT access without authentication. The Medium CVSS is the aggregate across all deployments; for any operator who has activated SSE mode (which the README promotes as a feature), the finding is functionally High.\n\n**Fix — four concrete changes:**\n\n1. Require `MCP_GITLAB_AUTH_TOKEN` as a startup precondition when `USE_SSE=true`. If the env var is unset, the server should exit with a clear message before the HTTP server starts:\n\n   ```typescript\n   if (process.env.USE_SSE === 'true') {\n     if (!process.env.MCP_GITLAB_AUTH_TOKEN) {\n       console.error(\n         'ERROR: MCP_GITLAB_AUTH_TOKEN must be set when USE_SSE=true. ' +\n         'SSE transport without authentication exposes all GitLab tools to unauthenticated callers.'\n       );\n       process.exit(1);\n     }\n   }\n   ```\n\n   The token check in `src/transport.ts` validates it on every request:\n   ```typescript\n   const authToken = process.env.MCP_GITLAB_AUTH_TOKEN;\n   if (authToken) {\n     const provided = req.headers['authorization']?.replace(/^Bearer /, '');\n     if (provided !== authToken) {\n       res.writeHead(401);\n       res.end(JSON.stringify({ error: 'Unauthorized' }));\n       return;\n     }\n   }\n   ```\n\n2. Bind to `127.0.0.1` by default for the SSE transport rather than `0.0.0.0`. An explicit `MCP_GITLAB_HOST=0.0.0.0` flag with a startup banner warning can expose it to the network for operators who need that — but the safe default should be loopback-only.\n\n3. Replace the wildcard `Access-Control-Allow-Origin: *` with a localhost-only default. When network exposure is intentional (explicit flag + auth token set), an explicit `CORS_ORIGINS` allowlist should be required.\n\n4. The SAML/OAuth3 roadmap item is the right long-term direction. In the interim — before that ships — the three changes above are entirely in the existing codebase with no new dependencies.\n\n---\n\nNo prior security advisories, CVEs, or public security issues exist for this package — a search of the repository issue list and npm advisory database did not yield any duplicate issues.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "@yoda.digital/gitlab-mcp-server"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.6.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/yoda-digital/mcp-gitlab-server/security/advisories/GHSA-8jr5-6gvj-rfpf"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-44895"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/yoda-digital/mcp-gitlab-server"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-306", "CWE-942" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-09T00:10:28Z",
    "nvd_published_at" : "2026-05-26T22:16:42Z"
  }
}